home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Workbench Design
/
WB Collection.iso
/
workbench werkzeuge
/
bildschirmschoner
/
madhouse
/
anleitung.guide
(
.txt
)
next >
Wrap
Amigaguide Document
|
1996-04-07
|
182KB
|
4,427 lines
@database Madhouse
@author "Carsten Jahn"
## Amiga-Guide-Dokument f
r den Madhouse-Screenblanker.
## Bitte AmigaGuide, MultiView oder einen Text-Anzeiger, der die .guide-
## Dateien anzeigen kann, benutzen.
## Solche Programme k
nnen auf den Disketten der AmigaLibDisk-Serie
## ("Fish-Disks") und auf vielen anderen Serien und von Mailboxen bezogen
## werden.
## Die Anleitung kann zwar auch so gelesen werden, aber es ist bedeutend
## schwieriger...
@node Main "Madhouse: Inhaltsseite"
@{B}Hallo Freunde der modularen Screenblanker!@{UB}
Vor Euch seht Ihr die Anleitung zu Madhouse - dem modularen Bildschirm-
"Schoner" den Ihr m
gen werdet.
Das beste an Madhouse sind sicherlich die Blanker, denn hier haben wir
uns wirklich M
he gegeben um interessante Effekte zu erstellen.
Doch auch das Hauptprogramm "Madhouse" welches die Module konfiguriert
und aufruft, hat einiges zu bieten. Aber seht selbst.
Um schnell die Blanker zu sehen bietet sich der Workshop an, der Euch bei
den ersten Schritten begleitet.
@{" Ein kleines Vorwort: Wer will das schon lesen? ",link preface}
@{" Der Workshop: Schnell einsteigen. ",link workshop}
@{" Die (Advanced) Options: Keine Festplatte? Pa
wort? ",link adv_op}
@{" Die Blankmodes: und alle Optionen... ",link blankers}
@{" Das Error System: Spa
mit Fehlern ",link errors}
@{" Der Referenz-Teil: Wie ging das doch gleich? ",link reference}
!! @{" F
r Non-HD-User: Alles
ber Buffering. ",link buffering} !!
@{" Nicht nur f
r C-Profis: Eigene Module hinzuf
gen ",link programmers}
@{" Registration, Sonstiges: der unvermeidliche - Anhang! ",link addon}
@endnode
@node preface "Ein Vorwort"
Als er mit feuchten Fingern den klobigen Schalter bet
tigte, sch
ttelte es
die Zahnr
der der Festplatte locker hin und her. Der Aluminiumscheibensta-
pel saugte sich an seine Vertikalachse, vier Schwenk
rme zwengten sich j
zwischen sie und entsandten Magnetfelder. Die Rotorbl
tter neben den
seriellen Stiftreihen zirkulierten um den L
ftermotor. Ein tiefes R
durchstr
mte den Raum. Die gelbe Leuchtdiode begann aufgeregt zu blinken,
mit einem Zittern w
rgte der Monitor das erste Bild hervor. Ein pinkfar-
bener, spitzer Pfeil nach Nord-West begann eifrig und hungrig Betonkl
mit farbigen Bildern zu attackieren. Ein Beben ging
ber die Tasten, die
sich voller Furcht in der Mitte der Tastatur zusammenkauerten. Drei-
hunderttausendmal wurde eine von ihnen von einem harten Fingerballen ge-
troffen. Pl
tzlich erlosch das Bild, der L
fter verstummte, und die Lampe
ging aus. Mist - Stromausfall. Und wieder nicht abgespeichert...
--
Nach diesem kurzen Drama wollte ich aber eigentlich noch etwas sinn-
volleres sagen. Als wenn die ersten zehn Zeilen auf der Inhalts-Seite nicht
gereicht h
tten, werde ich hier noch ein paar Anmerkungen loswerden, die
sich sonst in keines der Kapitel so richtig einreihen lassen.
@{FG Highlight}@{B}Ich, du, er-sie-es@{UB}@{FG Filltext}
Die deutsche Sprachsyntax erm
glicht die Verwendung einer H
flichkeits-
Form neben den normalen Anreden, die normalerweise benutzt wird wenn man
es mit jemanden zu tun hat, den man nicht kennt. Also k
nnte ich Sie
den gesamten Text hinweg siezen. Andererseits werden viele Leser auch
nicht gerade die
ltesten sein, weshalb ich das "Sie" nicht verwenden
werde. Das soll nat
rlich nicht die 80-j
hrigen User diskreminieren.
Kurzum, ich habe mich f
r Euch und Ihr entschlossen, was hier die gesamte
Amiga-Fangemeinde anspricht. Wer sich damit nicht anfreunden kann,
bitte sehr:
Sehr geehrte Dame, sehr geehrter Herr!
Wir gratulieren Ihnen recht herzlich zum Empfang der Madhouse-Distribution.
Dieses Programmpaket wird Ihnen noch lange Freude bereiten, denn wir haben
bei der Herstellung Wert auf ausgesuchte Materialien gelegt. Bitte lesen
Sie diese Gebrauchsanweisung sorgf
ltig durch.
Da wir uns ja nun schon seit 80 Sekunden kennen, erlaube ich mir, Ihnen
das Du anzubieten. Ich hei
e Carsten, und du? (Stellvertretend f
r Aicke
chte ich hier anmerken, da
Aicke Aicke hei
@{FG Highlight}@{B}Englische Eindeutschung und deutsche Einenglischung@{UB}@{FG Filltext}
Besonders die Einsteiger, die das "Commodore Benutzerhandbuch Workbench"
gelesen haben (m
glichst @{I}bevor@{UI} es auseinander fiel), wurden dort
mit einer F
lle von neudeutschen Begriffen konfrontiert, die sich in der
englischen Sprache viel besser anh
Von Bl
ttersymbolen, Amiga-DOS Stapeldateien, Piktogrammen, Voreinstellern,
Standardnamensmustern und nicht zuletzt Anmeldedateien ist hier die Rede.
Ich bin aber noch mit Cyclegadgets, Scripts, Icons, Prefs, Patterns und
Mountfiles aufgewachsen und finde z.B., da
sich "Lokalisationsvorein-
stellungsdialogfenster" etwas gedrungen anh
rt... weshalb ich haupts
lich Begriffe verwenden werde, wie man sie auch in Fachzeitschriften fin-
@{FG Highlight}@{B}Hausgemachtes Sprachen-Wirrwar auf Commodore-Art: die locale.library@{UB}@{FG Filltext}
Eine der tollsten (wenn auch eine der letzten...) Ideen, die Commodore
noch vor dem Konkurs vollbrachte, war die locale.library. Zu ihr geh
auch die ca. 50 Verzeichnisse und hunderte von Dateien, denn die locale.-
library ist komplett modular aufgebaut. Falls also Mars-Kolonien entstehen
sollten, oder ein Amiga an au
erirdische Lebensformen verkauft wird, oder
tzlich ein neuer Kontinent auftauchen sollte, dann kann man ganz pro-
blemlos die betreffenden Sprachen und Auslandsvorwahlen inclusive des
Zeitformats und der Wochentage einstellen.
Seit der Version 1.1 ist Madhouse lokalisiert. Das hei
t: Benutzer von
OS 2.1 oder h
her kommen in den Genu
eines Madhouse mit deutschen Texten,
OS 2.0 - User lesen nach wie vor alles auf englisch. Das stellt diese An-
leitung auf eine harte Probe: englische und deutsche Texte m
ssen gleich-
zeitig erw
hnt werden. Au
erdem unterscheiden sich teilweise die Texte
vom MUI-Programmteil von den Texten, die ohne MUI zu lesen sind.
@{FG Highlight}@{B}Leider ist Madhouse seit vorgestern Commoditie.@{UB}@{FG Filltext} Wieso leider? Nun, Aicke
und ich sind nicht gerade Fans von CX's (dumme Abk
rzung..), weil man
als Anwender immer das Problem hat, die Einstellungsfenster der Commo-
dities zu
ffnen. Denn viele C. bieten nur zwei M
glichkeiten dazu:
den Hotkey und das Exchange-Programm. Ersteres vergi
t man dauernd,
letzteres mu
man erst starten. Weil Exchange selbst Commoditie ist, k
te man es auch per Hotkey aufrufen, aber wenn man den auch vergessen
hat...
Naja, Commoditie-Hasser haben keine Probleme mit Madhouse, da man es ja
ganz bequem mit dem Tools-Men
aufrufen kann. Und die, die voll auf
Commodities abfahren, k
nnen Madhouse auch mit Exchange fernsteuern -
wenn's denn unbedingt sein mu
Madhouse ist aber nur deshalb Commoditie, weil sich das vom programm-
technischen Aspekt ganz gut macht, so lassen sich Maus und Tastatur leicht
und vor allem systemkonform abfragen.
@{FG Highlight}@{B}Was Madhouse von anderen herk
mmlichen Marken-Blankern unterscheidet:@{UB}@{FG Filltext}
Die gro
en Unterschiede liegen in den kleinen Details. So kann mit fast
jeder Programmiersprache ein Blanker f
r Madhouse erstellt werden, und
kinderleicht ist es auch. Als Beispiel f
r ein anderes Detail m
chte ich
die Madhouse-Zufalls-Funktion hervorheben, die zu gegebener Zeit einen der
Blanker ausw
hlt, damit er dann angezeigt werden kann. Weil dieses Kapitel
aber eh' schon gro
genug ist, und ich Euch den Code auf keinen Fall er-
sparen m
chte, m
t Ihr jetzt @{"Hier klicken!",link bl_rand}
Die anderen Features werden Euch beim Lesen der Anleitung bestimmt auch
auffallen.
@{FG Highlight}@{B}Ein paar Worte an die Einsteiger.@{UB}@{FG Filltext}
Die Bedienungsanleitungen von Programmen, gleich ob kommerziell oder PD,
nnen und sollen die Anleitung zur Bedienung des Computers nicht ersetzen.
Wer also seinen Amiga noch nicht so lange besitzt, der sollte einerseits
eine gute Computerzeitschrift lesen.
ber solche Zeitschriften kann man
etwas
ber Neuerscheinungen auf dem Amiga-Markt erfahren. Zum Einsteigen
rt aber meiner Meinung nach noch ein Einsteigerbuch, das auf Euren
Computer zugeschnitten ist. Solche B
cher sind noch erh
ltlich und sind
eigentlich immer um L
ngen besser als Commodores Orginal-Anleitung.
@{FG Highlight}@{B}Zum Schlu
@{UB}@{FG Filltext} bitte ich alle interessierten Programmierer, doch mal
ein eigenes Modul f
r Madhouse zu schreiben, da die Schnittstelle recht
gut beschrieben ist (in dieser Datei). Au
erdem geht alles wirklich einfach,
und kleine H
rden werden mehr als ausf
hrlich erkl
rt. Viel Spa
dabei.
@{FG Highlight}@{B}Zum absoluten Schlu
@{UB}@{FG Filltext} danke ich allen, die sich so lange mein Gequassel
durchgelesen haben... Schreibt uns mal! F
r Verbesserungsvorschl
Anregungen, Lob und Kritik sowie geistige Aufbauma
nahmen ("Wann kommt
denn endlich das Update?") sind wir immer offen. Die Adressen findet
Ihr einerseits im etwas
berdimensionierten (ich geb' es ja zu..)
Info-Fenster des Hauptprogramms (
ber Info-Button erreichbar) und im
@{"Autoren- und Copyright-Anhang",link authors}
@{B}Viel Spa
@{FG Highlight} @{FG Fill} .@{FG Filltext}
@{FG Highlight} //\ \ @{FG Fill} :@{FG Filltext} /\ : @{FG Fill} @{FG Filltext}( )@{FG Highlight} _______ @{FG Fill} /\/\/\/\ @{FG Filltext}
/\ @{FG Highlight} / \ \ @{FG Fill} _.._-. :@{FG Filltext} || '@{FG Fill} __ @{FG Filltext}(.)@{FG Highlight} /_______\ @{FG Fill}< >@{FG Filltext}
/ \ /\\\ @{FG Highlight} | _ \ @{FG Fill} 8 \ :@{FG Filltext} || /\ @{FG Fill} / \ @{FG Filltext}(.)@{FG Highlight} || ||@{FG Fill} < >@{FG Filltext}
/ \ / \ @{FG Highlight} | |_| \ @{FG Fill} 8 ___ \:@{FG Filltext} || ||@{FG Fill} I /\
@{FG Filltext}(
)@{FG Highlight} ||@{FG Filltext} ( )@{FG Highlight} ||@{FG Fill} > \/\/\/@{FG Filltext}
/ /\ \\// |@{FG Highlight} | |@{FG Fill} 8 | \ |@{FG Filltext} ||_||@{FG Fill} I || ! @{FG Filltext}(
)@{FG Highlight} ||@{FG Filltext} (:)@{FG Highlight} ||@{FG Fill} > <@{FG Filltext}
/ / \______ |@{FG Highlight} | ___ |@{FG Fill} 8 * < |@{FG Filltext} |___|@{FG Fill} I || ! @{FG Filltext}(
)@{FG Highlight} ||@{FG Filltext} (
)@{FG Highlight} ||@{FG Fill} < <@{FG Filltext}
/ / | |@{FG Highlight} || | |@{FG Fill} 8 | > |@{FG Filltext} || ||@{FG Fill} I || ! @{FG Filltext}(
)____/
/ @{FG Highlight}||@{FG Fill} < /\/\/\ @{FG Filltext}
/ | | |@{FG Highlight} || | |@{FG Fill} 8 |__/ |@{FG Filltext} || ||@{FG Fill} I || ! @{FG Filltext}\
++++++/ @{FG Highlight}// @{FG Fill} > >@{FG Filltext}
|___| | |@{FG Highlight} \/ : :@{FG Fill} 8 / @{FG Filltext} \/ ||@{FG Fill} | \/ ! @{FG Filltext}
@{FG Highlight}// @{FG Fill} > \/\/\/@{FG Filltext}
| |@{FG Highlight} . :@{FG Fill} 8_..../ @{FG Filltext} ||@{FG Fill} \__/ @{FG Highlight} ____// @{FG Fill} < <@{FG Filltext}
| |@{FG Highlight} .@{FG Fill} 8 @{FG Filltext} \/@{FG Fill} @{FG Highlight} /____/ @{FG Fill} < <@{FG Filltext}
\/\/@{FG Highlight} . @{FG Fill} 9 @{FG Filltext} @{FG Fill} @{FG Highlight} // @{FG Fill} > /\/\/\ @{FG Filltext}
@{FG Highlight} .@{FG Fill} 0 @{FG Filltext} @{FG Fill} @{FG Highlight} || /\ @{FG Fill} > >@{FG Filltext}
@{FG Highlight} @{FG Fill} 1 @{FG Filltext} @{FG Fill} @{FG Highlight} \\____//: @{FG Fill} < >@{FG Filltext}
@{FG Highlight} @{FG Fill} : @{FG Filltext} @{FG Fill} @{FG Highlight} \____/ @{FG Fill} \/\/\/\/@{FG Filltext}
w
nschen Euch die Programmierer
Aicke Schulz und Carsten Jahn.@{UB}
@endnode
@node bl_rand "Die Madhouse-Zufallsfunktions:"
Also, beim Durchschnittsblanker w
rde man so eine Funktion etwa so
realisieren:
short bl_random()
return Random(b_counter)
wenn b_counter die Anzahl der Blanker ist.
In Madhouse sieht das so aus:
short bl_random()
short rd=0;
BOOL takeIt = FALSE;
BOOL Bl_Avail = FALSE;
short used_min = 30000;
short used_max = 0;
short take_me_border = 0;
// CPU-Tests?
short cpu = 0;
if( cpu_sensitive ) // Wenn CPU sensitive Random aktiv ist
cpu = cpu_test(); // Zustand der CPU ermitteln (macht sie was?)
// Ist
berhaupt ein Blanker verf
gbar?
for( int i=0; i<b_counter; i++ ) {
// Wurde der Blanker ausgew
hlt und lief bei ihm noch nichts schief?
if( (b[i].rand_sel == TRUE) && (b[i].error == FALSE) ) {
// Tritt folgender Fall nicht ein: CPU sensitive Random gew
// UND CPU ist belastet UND der Blanker braucht CPU?
if( !(cpu_sensitive && cpu && b[i].CPU_need == 1) ) {
// Nein, dieser ist schon mal tauglich und wir haben einen
// Dummen gefunden, der die Arbeit macht.
Bl_Avail = TRUE;
// Es wird ermittelt, wie oft dieser Blanker schon in dieser
// Blank-Periode ben
tigt wurde. Dieser Wert steht in [].used.
//
fter oder weniger als alle anderen?
if( b[i].used < used_min ) used_min = b[i].used;
if( b[i].used > used_max ) used_max = b[i].used;
}
}
// Jetzt enthalten: used_min wie oft der Blanker schon dran war, der am
// wenigsten dran war und
// used_max wie oft der Blanker schon dran war, der am
// meisten dran war.
take_me_border = used_min + (used_max-used_min)/2;
// Die Gruppe der Blanker wird zweigeteilt. Einen Auftrittsz
hler klei-
// ner oder gleich take_me_border bedeutet, er war weniger dran als DIE
// H
LFTE der Blanker, will sagen da
eine Menge Blanker schon
// dran war als er.
// Besser kann ich das nicht erkl
ren...
if( Bl_Avail ) {
// Solange noch keiner herausgefischt wurde
while( !takeIt ) {
takeIt = TRUE;
// Einen aus der Menge greifen
rd=Random(b_counter);
// Und sehen, ob er den Anforderungen gen
// Wurde er etwa nicht ausgew
hlt? Dann nix wie weg mit ihm.
if( b[rd].rand_sel == 0 ) takeIt = FALSE;
// Oder hatte er in dieser Blank-Periode schon einen Fehler ge-
// meldet? Dann geht er jetzt sich auch nicht... und tsch
if( b[rd].error == TRUE ) takeIt = FALSE;
// Oder wurde CPU sensitive Random ausgew
hlt UND die CPU ist
// am kochen UND er w
rde den Prozessor zu stark beanspruchen?
if( cpu_sensitive && cpu && b[rd].CPU_need ) takeIt = FALSE;
// Oder haben wir den vorhin schon gesehen?
if( b[rd].used > take_me_border ) takeIt = FALSE;
}
} else
// Kein Wunder - niemand hat sich gefunden...
rd = -1;
return rd;
// Ergebnis ist -1, wenn kein passender Bl beschafft werden konnte.
Kleine Anmerkung: Obwohl - wie hier ersichtlich - die Blankerdaten in einem
Array gehalten werden, ist die Anzahl der maximal m
glichen Blanker nicht
limitiert. Dies k
nnt ihr gerne durch hundertausendfaches Kopieren des
CrazyPixel-Blankers nachpr
fen. Ich habe das nicht ausprobiert...
@endnode
@node workshop "Der Workhop"
Soo, da w
ren wir nun. Eigentlich ist die gesamte Madhouse-Oberfl
selbsterkl
rend, wie man so sch
n sagt. Aber wer kann schon von seinenen
Programmen behaupten, da
sie jeder versteht? Vielleicht Dr. Peter Kittel
von seinen AmigaBASIC-Demos? Also dann, ab gehts:
@{FG Highlight}@{B}0. Die Installation.@{UB}@{FG Filltext}
... sollte eigentlich ganz einfach gehen, denn das Installerscript zu
Madhouse erledigt alles. Das dazu n
tige Programm "Installer" solltet
Ihr von Eurer Install-Disk (sofern Ihr eine habt, sonst von einem
anderen Programm das den Installer verwendet) in Euer C:-Verzeichnis
kopieren, dann m
te alles laufen.
Wer absolut nicht an den Installer herankommt, was jetzt aber echt ver-
wunderlich ist, der mu
halt alles "handy" machen:
@{B}a) Zum schnellen Ausprobieren:@{UB} die amos.library aus dem Madhouse-Libs/-
Verzeichnis in das libs-Verzeichnis der Startdiskette/-Festplatte
kopieren. Das kann
ber die Shell so geschehen:
"copy Madhouse/libs/amos.library to sys:libs/amos.library".
Vor "Madhouse" mu
ggf. noch ein Pfad mit Diskettenbezeichnung stehen.
Das war's dann schon, denn wenn das Programm "Madhouse" aus seiner ur-
spr
nglichen Schublade heraus gestartet wird, findet es das Ein-
stellungsprogramm von allein.
@{B}b) Zur dauerhaften Anwendung:@{UB} Wie das Wort "dauerhaft" schon andeutet,
mu
hier wieder die Schublade SYS:WBStartup/ herhalten. Aber zuerst die
amos.library kopieren, wie unter a) beschrieben.
Nun das Programm "Madhouse" nach SYS:WBStartup kopieren. Alle Programme
in dieser Schublade werden dann beim Hochfahren des Rechners automa-
tisch gestartet. Benutzer von Disketten sollten das gesamte Madhouse-
Verzeichnis auf einer neuen Leerdiskette auslagern, HD-User legen ein
neues Verzeichnis an und kopieren die Madhouse-Schublade dort hinein.
Jetzt mu
nur noch das ToolType ("Merkmal") im Madhouse-Icon (dem Mad-
house-Piktogramm in WBStartup) ge
ndert werden. Die Zeile CONFIGED=
sagt Madhouse, wo sich das separate Einstellungsprogramm f
r Madhouse
befindet, welches Madhouse ggf. selbst starten mu
. Man mu
diesen
ToolType so
ndern, da
er den neuen Pfad und den Programmnamen des
MadhouseConfigEd-Programs enth
lt - also je nach dem, wohin man das
Madhouse-Verzeichnis kopiert hatte.
Damit - falls dies ein Amiga mit OS 2.1 oder h
her ist - Madhouse die
mitgebrachte Locale-Datei benutzen kann, um alles auf deutsch anzu-
zeigen, mu
noch die Datei
Locale/deutsch/madhouse.catalog
aus dem Madhouse-Verzeichnis nach
LOCALE:catalogs/deutsch/madhouse.catalog
kopiert werden - und fertig.
@{FG Highlight}@{B}1. Der Programm-Start.@{UB}@{FG Filltext}
Das sollte kein gro
es Problem darstellen. Wie auf dem Amiga
blich,
geschieht dies per Doppelklick auf das Madhouse-Icon.
Falls der Computer nicht mit dem Amiga-OS 2.0 ausger
stet ist,
ist das schlecht, denn in diesem Fall gibt Madhouse nicht mehr als
einen simplen Alert aus...
Au
erdem *mu
* die amos.library im "LIBS:"-Verzeichnis vorhanden sein,
aber das haben wir ja eben erledigt. (Nur, falls jemand mittels
"assign add LIBS: xxx" mehrere Suchpfade f
r LIBS: erstellt hat, noch
ein Hinweis: die amos.library mu
sich in dem Verzeichnis befinden,
was zuerst als LIBS: deklariert wird, also normalerweise sys:libs.
Sonst st
rzt der n
chstbeste AMOS-Blanker ab. Sorry, aber so ist das
halt bei AMOS.)
@{FG Highlight}@{B}2. Ein Fenster
ffnet sich.@{UB}@{FG Filltext}
Und das ist schon einen Faszination f
r sich, denn bei installiertem
MagicUserInterface (
Stefan Stunz, folgend MUI genannt, siehe auch
@{"MUI-Infos",link mui_info}) reagiert der MadhouseConfigEd entsprechend und
ffnet ein MUI-Fenster, sonst nur ein normales. Ihr habt richtig ge-
lesen, im Moment und eigentlich immer bedient Ihr den MadhouseConfigEd
und nicht Madhouse selbst. (Madhouse hat soeben dieses Programm ge-
startet).
Falls nicht, wenn sich also kein Fenster
ffnet, ist bereits alles in
Ordnung. Beim Erststart wird Madhouse allerdings nicht seine Datei mit
den Einstellungen finden k
nnen, so da
es das Hauptfenster
ffnet.
Wenn Ihr das Fenster "von Hand"
ffnen wollt, dann
- braucht Ihr keinen Hot-Key zu dr
cken, den Ihr immer verge
t, und
- Ihr braucht nicht das Exchange-Programm zu starten, das Ihr immer
l
scht...
Ein Blick ins Tools-/Hilfsmittel-Men
bringt Klarheit, Madhouse tr
sich praktischerweise hier ein. Bei Anwahl Fenster.
Wenn anstatt eines tollen Fensters ein fader Requester erscheint, der
etwas von einem falschen Pfad labert, dann folgt den Anweisungen und
beendet Madhouse (Requester best
tigen und Madhouse nochmals starten),
ndert den CONFIGED-Tooltype (siehe Abschnitt 0) und startet Madhouse
neu.
@{FG Highlight}@{B}3. Jetzt den Pfad der Blanker angeben!@{UB}@{FG Filltext}
Durch einen Klick auf den kleinen Knopf mit dem Bildchen (neben dem
Path-Gadget)
ffnet sich der ASL-Directory-Requester, in dem ihr jetzt
das Verzeichnis mit den Blankern angeben k
nnt. Auf der unge
nderten
Madhouse-Disk hei
t dieses Verzeichnis "Blankers". Wichtig: Der Pfad
mu
mit dem NAMEN einer Diskette beginnen (z.B. "Work:.../Blankers"),
sonst macht Euch Madhouse darauf aufmerksam und akzeptiert nix.
Nachdem der Requester mit "Ok" best
tigt wurde, sollten in der Listbox
auf der linken Seite des Hauptfensters Namen wie "FlyingToasters"
stehen. Au
erdem werden nun die restlichen Gadgets nicht mehr
schraffiert dargestellt.
r Einsteiger, die ihren Wortschatz aufstocken wollen: Dieses Gadget
"mit dem Bildchen" hei
t Popup-Button.
@{B}- Wer keine Festplatte hat...@{UB}
der kann Madhouse auch benutzen. Jedoch mu
dann der Schalter
"Puffern/Buffering" im Advanced-Options-Fenster bzw. auf der Optionen/
Advanced-Seite im MUI-Fenster aktiviert sein.
Das geschieht schon standard-m
Da Madhouse sehr gut auf den Diskettenbetrieb abgestimmt ist, aber
oberfl
chlich davon nur dieses "Puffern/Buffering"-Gadget zu sehen ist,
empfehle ich noch die Lekt
re von @{"Alles
ber Buffering",link buffering}.
@{B}- Wer aber eine Festplatte hat...@{UB}
Der kann die Option "Puffern/Buffering" im Advanced-Options-Fenster (bei
MUI: auf der Optionen/Advanced-Seite) ausschalten.
Doch dazu sp
ter mehr. Nat
rlich reicht es nicht, eine Festplatte zu
haben, Madhouse mu
auch dort installiert sein...
@{FG Highlight}@{B}4. Nun sehen wir uns die Blanker-Module an!@{UB}@{FG Filltext}
@{B}Ohne MUI:@{UB}
Zuerst mu
das Edit-Gadget durch draufklicken weitergeschaltet werden,
bis der Text "Einstellung/Prefs..." erscheint. In diesem Modus k
die Einstellungen des Blankers ge
ndert werden, den man in der unteren
Liste ausw
hlt. Also bitte einen Blanker anw
hlen!
@{B}Mit MUI:@{UB}
Zuerst m
t Ihr das Registerfeld (oder das Cycle-Gadget) von "System"
auf "Blankers" umschalten. Nun erscheint wieder fast dieselbe Liste
auf der linken Seite des Fensters. Bitte auf einen Blanker doppel-
klicken.
@{B}Weiter f
r mit und mit ohne :^) MUI:@{UB}
Schon
ffnet sich ein Fenster, in dem sich u.a. ein Knopf mit der
Aufschrift Test befindet. Anklicken und staunen!
Durch einen weiteren Mausklick wird der Blanker dann wieder beendet.
"Abbruch/Cancel" und "Okay"
ffnen wieder das Hauptfenster, wobei "Okay"
die Einstellungen abspeichert. "Dauer/Duration" (bei MUI im Haupt-
fenster, sonst im eben ge
ffneten BlankerPrefs-Fenster) wird im Refe-
renzteil erkl
Die anderen Gadgets variieren je nach Blanker. Hier bieten sich
viele M
glichkeiten zum Herumspielen, beeinflussen diese Gadgets doch
den Blanker. Ihre Bedeutungen werden dann im Blanker-Kapitel erkl
Jetzt k
nnt Ihr erstmal alle Blanker ausprobieren.
@{FG Highlight}@{B}5. Die Liste(n) mit den Blanker-Namen und was da so passiert:@{UB}@{FG Filltext}
@{B}Ohne MUI:@{UB} Der Edit-Button bestimmt, was passiert, wenn ein Blanker in
der Liste ausgew
hlt wird.
Steht er auf "Einstellung/Prefs..." kann, wie eben geschehen, das
BlankerPrefsFenster ge
ffnet werden.
Mit "Auswahl/Selection" wird bestimmt, welche Blanker benutzt werden,
wenn Madhouse nach der angegebenen Zeit die Blanker startet.
Durch Klick werden sie angeschaltet (
CrazyPixel) und wieder
ausgeschaltet ( CrazyPixel).
@{B}Mit MUI:@{UB}
Die Liste, die auf der Blankers-Seite angezeigt wird, erm
glich das
dern der Einstellungen der einzelnen Blanker. Die andere Liste, auf der
System-Seite vorhanden, dient dem Ausw
hlen der einzelnen Blanker. Mit
Ihr wird bestimmt, welche Blanker gestartet werden sollen, wenn der
Computer
ber eine einstellbare Zeitspanne hinweg keine Eingaben
empfangen hat.
@{FG Highlight}@{B}6. Wieviel Zeit meiner Inaktivit
t soll vergehen, bis Madhouse loslegt?@{UB}@{FG Filltext}
Diese Einstellung wird mit dem "Zeit/Time"-Slider erledigt.
@{FG Highlight}@{B}7. Konfiguration speichern.@{UB}@{FG Filltext}
Ganz einfach mit "Speichern/Save". Dann wird die Konfiguration als
"ENVARC:Madhouse.prefs" abgespeichert.
@{FG Highlight}@{B}8. Wer keine Festplatte hat oder ein Pa
wort braucht,@{UB}@{FG Filltext}
Klickt hier: @{"Die (Advanced) Options", link adv_op}
@endnode
@node adv_op "Das Advanced Options Fenster / Die Advanced/Optionen-Seite"
Dieses Fenster stellt einige weitere Funktionen bereit, die man
selten
ndert.
@{FG Highlight}@{B}1. Pa
rter@{UB}@{FG Filltext}
r Zeitgenossen, die anderen alles zutrauen und f
r Leute, die den
Amiga beruflich nutzen (ja, das gibt's!), haben wir eine Pa
wort-
Funktion zur Verf
gung gestellt, die sich kaum umgehen l
t (was
mir bereits zum Verh
ngnis wurde...)
"Kaum" hei
t, es wurde durch keinen Versuch die Sicherheit des
Eingabescreens widerlegt. Und wir haben wirklich alles ausprobiert.
Jedoch kann Madhouse auf Systemen ohne Festplatte den neuen Blanker
nach @{I}Abbruch@{UI} der Pa
worteingabe nicht so schnell starten, was
zur Folge hat, da
in dieser Zeit dann doch Ver
nderungen an den Pro-
grammen im Hintergrund vorgenommen werden k
nnen. Also ausprobieren!
Wenn Ihr ein Pa
wort wollt, m
t Ihr zun
chst den Haken vors
"Password/Pa
wort/Benutzen"-Gadget setzen. Dann sollte noch ein m
lichst gerissenes Pa
wort in das Text-Feld "Name" (bzw. "Text") einge-
geben werden. 4711 w
rde nat
rlich jeder Gangster zuerst ausprobieren,
besser sind da ausgefallenere Dinge: "Schnellhefter", "ALDI", "Rasen-
her", "Hundshai", ... Ach, ja.. es ist recht hilfreich, wenn man das
Pa
wort nicht vergi
t. Nach der Einstellung des Pa
worts fragt Madhouse
gleich nach demselben; was sich also nicht eingeben l
t wird gleich und
ohne Probleme durch das alte Pa
wort ersetzt.
Nachdem ein Blanker gestoppt wurde, erscheint dann der Pa
wort-Screen.
Es ist zwar kein Cursor im Textfeld zu sehen, aber Ihr k
nnt einfach
lostippen. Jedes Zeichen wird als "*" dargestellt. Es gibt drei
Chancen, das richte Pa
wort zu finden, aber ist das dritte falsch,
verstreichen ein paar Minuten seit der letzten Eingabe, oder es
wird Esc gedr
ckt, startet der n
chste Blanker. Backspace funktioniert
wie gewohnt, und Return best
tigt das Pa
wort. Zwischen Gro
- und
Kleinschreibung wird fieserweise unterschieden!
@{FG Highlight}@{B}2. Optionen f
r Disketten-Benutzer@{UB}@{FG Filltext}
Wenn Ihr keine Hard-Disk habt, ist Madhouse der einzige modulare
Screenblanker, den Ihr benutzen k
nnt (soweit ich wei
Was passiert wohl, wenn man einen herk
mmlichen Marken-Mod.-Screenbl.
startet, der seine Module nur auf einer Diskette sucht? Sofern beim
Start des Blankvorgangs mal die ben
tigte Disk nicht im Drive liegt,
startet die Workbench ihre eigene Show: Ein netter "Please insert
Disk..."-Requester brennt sich in Eure Phosphorschicht.
Wenn man "Puffern/Buffering" im Advanced-Options-Fenster aktiviert, ist
soetwas mit Madhouse nicht m
glich. Madhouse l
dt dann immer einen
Blanker in sein RAM:Madhouse_Storage-Verzeichnis, das es beim Programm-
Start automatisch anlegt. Wurde dieser Blanker dann gezeigt, und die
Diskette mit den Madhouse-Blankern liegt WIRKLICH im Drive (wird vor-
sichtig gepr
ft), dann l
dt Madhouse einen frischen Blanker nach.
Wenn Ihr zus
tzlich "@{B}Nach Disk fragen/Ask for Disk@{UB}" anw
hlt, zeigt Euch
Madhouse mit einem kleinen Fenster auf der Workbench an, da
der ge-
pufferte Blanker bereits benutzt wurde und da
Madhouse darauf lauert,
da
die Blankers-Diskette eingelegt wird.
Ein Klick auf das Schlie
-Gadget dieses kleinen Fensters bewirkt nicht
nur das Schlie
en des Fensters, sondern stellt auch alle Schn
ffel-
versuche nach der Diskette ein.
Madhouse kopiert au
erdem die libs:amos.library in sein Storage-
Verzeichnis, da die Amos-Blanker diese ben
tigen.
@{FG Highlight}@{B}3. Der "Schwarze Hintergrund/Black Background"@{UB}@{FG Filltext}
Wer Disketten benutzt, hat sicher schon die oft sekundenlangen
Ladezeiten der Blanker bemerkt. Wer mehrere Blanker ausgew
hlt hat
und "Blanker wechseln/Exchange Blankers" benutzt, bekommt beim Blanker-
wechsel immer kurz die Workbench zu sehen (sofern die Disk mit den
Blankern im Laufwerk liegt, sonst kann Madhouse ja nicht wechseln).
Wenn Euch das st
rt, k
nnt Ihr "Hintergrund
ffnen bzw. Benutzen / open
Background" aktivieren. Dann bleibt der Screen in den Ladezeiten
schwarz. Wer zus
tzlich "Info-Texte/and show info-texts" anw
hlt, be-
kommt auf diesem schwarzen Screen noch die Texte "Lade neuen Blanker/
Loading new blanker." und das beliebte "Bitte noch etwas Geduld.../Wor-
king. Please wait..." angezeigt!
@{FG Highlight}@{B}4. Die anderen Optionen: "Other Options"@{UB}@{FG Filltext}
Das Fenster der erweiterten Optionen bietet auch noch zwei "andere
Optionen": Beginnen wir mit der interessanteren: "@{FG Highlight}CPU active:@{FG Filltext}"
Zuerst einmal mu
erkl
rt werden, da
verschiedene Programme und
bestimmte Dinge den Prozessor Eures Computers mehr oder weniger be-
lasten. Generell kann man sagen, da
die sog. CPU ausgelastet ist,
wenn ein Programm etwas tut und Ihr warten m
t. Z.B. bei irgend-
welchen Rechnungen.
hrend PC-Freaks noch froh sind, wenn sie gleichzeitig einen Text
Drucken UND eine Diskette formatieren k
nnen, k
nnt Ihr auf Eurem
Amiga ohne gr
ere Probleme ein Bild berechnen und einen Text schrei-
ben. Man beachte, da
das mit dem Amiga 1986 m
glich war, und da
IBM 1994 mit OS 2 daf
r Werbung macht...
Also zur
ck. Wenn nun zwei @{I}rechenintensive@{UI} Programme gleichzeitig
laufen, also praktisch zwei Bilder berechnet werden, werden beide
Bilder halb so schnell berechnet.
Und jetzt kommts: Wer ein Bild berechnet und dabei einen
rechenintensiven Bildschirmschoner laufen l
t, merkt 1. da
Bild halb so schnell berechnet wird und da
2. der Blanker halb so
schnell l
uft. Und das ist gleich zweifach
rgerlich.
Deshalb gibt es in Madhouse das "CPU active:"-Gadget. Es hat drei m
liche Zust
- "alle Blanker/use all Blankers" k
mmert sich nicht um die CPU, so da
der o.a. Fall eintreten k
nnte.
- "(nur) einfache Blanker/only simple ones"
berpr
ft die CPU, ist sie
aktiv wird ein Blanker gestartet, der die CPU fast gar nicht belastet.
Wurden nur Blanker ausgew
hlt, die viel Rechenzeit ben
tigen, er-
scheint ein schwarzer Bildschirm und sp
ter die Mitteilung, die auf
diesen Notstand aufmerksam macht.
- "nichts anzeigen/show nothing" zeigt den schwarzen Screen immer, wenn
die CPU besch
ftigt ist.
Diese Funktion ist
brigens voll kompatibel zur "Puffern/Buffering"-
Option. Nur falls der gepufferte Blanker "viel" CPU braucht, ein Progr.
auch viel CPU braucht und "CPU active:" auf "only simple Blankers"
steht UND die Disk mit den Blankern nicht im Laufwerk liegt, seht Ihr
auch den schwarzen Screen.
Wenn Ihr wissen wollt, wie sowas im Programmcode aussieht, dann fragt
lieber nicht...
Wenn Ihr wissen wollt, welche Blanker denn nun rechenintensiv sind und
welche nicht, hier steht es:@{"die Blanker",link blankers}.
Mit MUI l
t sich das einfacher herausfinden, einfach auf die "Blan-
kers"-Seite wechseln und den fraglichen Blanker @{i}einmal@{UI} anklicken.
Dann wird im Feld "CPU-Belastung/CPU load" folgendes angezeigt:
- "niedrig/low" wenn der Blanker nicht rechenintensiv ist; und
- "mittel bis hoch/medium to high" wenn er es ist.
Die zweite Option dieser Rubrik hei
t "@{FG Highlight}Blanker-Pri@{FG Filltext}" und ist
ber ein
(echt niedliches) Cycle-Gadget erreichbar. Wie der Name verspricht,
nnt Ihr damit bestimmen, mit welcher Priorit
t die Blanker laufen
sollen. Eine Taskpriorit
t kann zwar zwischen -128 und 127 tendieren,
sinnvoll sind hier aber die Werte 0 und 1. Deshalb das Cycle-Gadget.
r den Fall, da
zwei Programme gleichzeitig rechnen, hat der
Amiga die Task-Priorit
ten. Dann wird das Programm mit der h
heren
Priorit
t zuerst abgearbeitet, das Programm mit der niedrigeren bekommt
nur noch ganz wenig vom Prozessor. Normalerweise laufen alle Anwendungen
mit der Priorit
Rechnet nun also ein Programm (kanonisches Beispiel: Raytracer)
und ein rechenintensiver Blanker wird mit der Priorit
t 1 gestartet,
bleibt dieses praktisch stehen. Deshalb sollte man bei "CPU active:" =
"alle Blanker/use all Blankers" immer 0 w
hlen.
Da bei "CPU active:" = "(nur) einfache Blanker/only simple Blankers" so-
wieso nur ein Blanker mit niedriger CPU-Belastung gestartet wird, wenn
ein Programm rechnet, kann man in diesem Fall ruhig 1 w
hlen. Dann l
der Blanker viel fl
ssiger und die Anwendung kann trotzdem weiterrech-
nen. Trotzdem mu
das nicht die beste Einstellung sein, denn wenn einem
Programm mitten beim Blanken anf
ngt zu rechnen, geht es ziemlich leer
aus. Ein Beispiel w
re ein Backup-Programm, was abwechselnd Dateien
packt und schreibt. Das Packen ist rechenintensiv, das Schreiben weni-
ger. Wenn nun Madhouse die Prozessorauslastung gerade beim Schreiben
berpr
ft, kann es gut sein, da
ein Blanker mit hoher CPU-Belastung
gestartet wird, und das Backup-Programm beim Packen arg verlangsamt
wird.
Und dann gibt's noch - vorerst nur f
r MUI-User - den "@{FG Highlight}Sound@{FG Filltext}"-
Button. Mit ihm l
t sich bestimmen, wie das Sound-System von Madhouse
arbeiten soll. Auf der Blanker-Seite kann man ja f
r jeden Blanker ein
Musik-Modul einstellen, was dann nat
rlich irgendwie abgespielt werden
mu
. Das ist vielleicht total schade, aber ich war tats
chlich zu faul
einen kompletten Musik-Modul-Abspieler mit 70 unterst
tzen Formaten und
modularen Konzept auf Assemblerbasis mit diversen Zusatzfunktionen zu
programmieren. Aus zwei Gr
nden: 1. ich kann kein Assembler (was soll
man denn noch alles k
nnen, Computer sind in mancherlei Hinsicht echt
anspruchsvoll), und 2. sowas gibt's schon. (Ok, das Argument zieht nicht
ganz, es gibt auch schon etliche Screenblanker).
Deshalb bin ich die Sache anders angegangen: Madhouse spielt nicht, son-
dern l
t spielen. Dabei kann Madhouse zwei Sound-Quellen ansteuern:
1. die medplayer.library vom MED-Programmierer Teijo Kinnunen, die sinn-
gem
nur MED spielt und
2. DeliTracker von Delirium Softdesign (Peter Kunath and Frank Riffel).
Der DeliTracker ist der h
rteste Modul-Player, den ich kenne. Er
spielt so gut wie alles, und wird per ARexx ferngesteuert.
Ihr k
nnt nun zwischen einer der Varianten w
hlen, und zwar mittels
des Sound-Gadgets. Obwohl Madhouse den DeliTracker mittels ARexx steu-
ert, mu
dazu nicht das Programm RexxMast aus der System-Schublade
laufen (darf aber). Die ARexx-Kommunikation zwischen zwei Programmen
kann vollst
ndig
ber die rexxsyslib.library erfolgen, die dann auto-
matsch in Euren Speicher gestopft wird.
Wenn Ihr also mehr als MED-Module abspielen wollt, dann mu
die Ein-
stellung "via DeliTracker" lauten. ("via" hei
brigens "auf dem Wege
ber" und ist damit das lateinische Pendant f
r einen ARexx-Port, blo
rzer!)
Wer
@{B}Es ist mir sehr wichtig, dies auch hier nochmals zu erw
hnen: f
r die
Sound-Funktionen von Madhouse ist eine Festplatte notwendig, damit die
betreffende Datei erreichbar ist.@{UB}
@endnode
@node blankers "Alle Blanker in der
bersicht"
Hier ist der Nachschlageteil f
r unsere Blanker, alphabetisch geordnet
und mit allen n
tigen Infos.
@{" CrazyPixel ", link b_crazypixel}
@{" DigitalClock ", link b_digitalclock}
@{" Drops ", link b_drops }
@{" Fireworks ", link b_fireworks }
@{" FlyingToasters ", link b_flyingtoasters }
@{" Glitter ", link b_glitter }
@{" Memory ", link b_memory }
@{" Note ", link b_note }
@{" Shuffle ", link b_shuffle }
@{" Skyline ", link b_skyline }
@{" Soccer ", link b_soccer }
@{" SoftwareFailure ", link b_softwarefailure }
@{" Stars ", link b_stars }
@{" Thunder ", link b_thunder }
@{" Waves ", link b_waves }
@{" Worldtime ", link b_worldtime }
@{FG Highlight}@{B}Bitte beachten:@{UB}@{FG Filltext} Der Duration-Slider und die Gadgets am unteren Rand des
BlankerPrefs-Fensters sind in @{"Referenz/BlankerPrefs-Fenster", link ref_editPrefs} er-
rt. Der Wert des "Dauer/Duration"-Sliders wird nicht mit Okay abgespei-
chert, sondern NUR mit der Save-Funktion im Hauptfenster. Trotzdem mu
dann das BlankerPrefs-Fenster mit Okay verlassen werden, damit der Wert
akzeptiert wird.
@endnode
@node b_crazypixel "Die Blanker in der
bersicht - CrazyPixel"
@{FG Highlight}@{B}CrazyPixel@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Dieser Blanker zeigt einen springenden Punkt sowie den Wusel.
Mode/Modus: schaltet zwischen Wusel und Bouncing Point um.
Ist Random ausgew
hlt, wird zuf
llig ein Modus
benutzt.
Wusell
nge/Wusel lenght: ist die L
nge des Wusels.
Toneffekt/Sound: macht Ger
usche zum Bouncing Point.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:160 kB. Programmgr
e:25 kB.
@endnode
@node b_digitalclock "Die Blanker in der
bersicht - DigialClock"
@{FG Highlight}@{B}DigitalClock@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Wie viele andere Blanker hat auch Madhouse eine Uhr. Diese benutzt aber
einen echten Digital-Font, wie er auch bei den beliebten Uhrenradios
zu finden ist. Achtung: Wenn die Uhr falsch geht, dann liegt das ent-
weder daran, da
die interne Uhr des Amigas falsch gestellt ist oder da
ihr kein Akku zur Verf
gung steht.
Sprache/Language: Hier k
nnen auch ein deutsches Datum und deutsche Texte
f
r diesen Blanker gew
hlt werden.
Countdown: Wenn dieser Wert nicht Null ist, ert
nt ein Klingeln
nach <Countdown> Minuten nach dem Start des Blankers.
Datum/Date: schaltet das Datum ein.
Rollen/Scroll: bewegt die Uhr.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr
e:34 kB.
@endnode
@node b_drops "Die Blanker in der
bersicht - Drops"
@{FG Highlight}@{B}Drops@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Tropfen laufen
ber den Screen. Sie haben unterschiedliche Geschwindigkeit-
en und sind in der Farbe
nderbar. Aicke hat mit viel Liebe zum Detail
die Drops gezeichnet. Von hunderten von Farbsets sind die sch
nsten aus-
hlt worden. Sie faszinieren mit ihren warmen, hellen Eindr
cken oder
lassen die Gedanken des Betrachters im tiefen Blau versinken. Ohne zu
bertreiben mu
ich sagen, da
diese Farben wirklich einmalig in der ge-
samten Welt der Amiga-Screensaver sind. Doch stellen wir sie einzeln vor:
Ocean wird seinem Namen wirklich gerecht. Ocean zeugt noch von der Zeit,
als die Ozeane klar und unverseucht waren. Ein heutiges Ocean halte ich
r unm
glich, m
ten doch Giftm
sser und russische Atom-U-Boote durch-
schimmern. Wine ist von seiner ganzen Farbpracht ein Genu
. Es springt
regelrecht aus dem Monitor und und bezaubert durch die Anmutigkeit der
Farbe. Grass erz
hlt von gr
nen Wiesen, spielenden Kindern und grasenden
Schafen. Grass ist wie ein Tag im Wald, l
t den Zuschauer frei assoziieren
und die Augen mit dem tiefen Gr
n verschmelzen. Caramel: Gold-gelb und
sooooo sanig-s
. Das hat mir mein Gro
vater schon geschenkt. Und was
gebe ich heute meinem Enkel? Fresh erinnert an einen Sonntagmorgen, an
die Str
nde von Miami Beach und Ibiza. So hell ist die Farbe, da
sich
kaum das Licht darin bricht. Fresh ist frisch. Da soll Aicke mal sagen,
ich w
rde seine Blanker kurz abhandeln... Gr
e an alle Kunstlehrer!
Anzahl/Number: Anzahl der Drops, die maximal gleichzeitig auf dem Screen
sind.
Farbe/Color: Der absolute MEGA-Mix der 5 Farbpaletten. Random l
t den
Blanker selbst w
hlen.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr
e:17 kB.
@endnode
@node b_fireworks "Die Blanker in der
bersicht - Fireworks"
@{FG Highlight}@{B}Fireworks@{FG Filltext}@{UB}
Von Carsten Jahn, Version 1.
Dieser Blanker zaubert ein tolles Feuerwerk auf Euren Bildschirm. Es
stehen vier Effekte zur Verf
gung. Mit den Slidern bestimmt man, wie
oft ein Effekt verwendet wird. Wenn die Slider nicht zu hoch gesetzt
werden, hat FireWorks noch M
glichkeiten, die Farben zu
ndern. So ent-
stehen immer neue Farben, obwohl kein Effekt "mittendrin" die Farbe
wechseln mu
. Will sagen: man merkt nur, da
tzlich ein neuer Effekt
in einer neuen Farbe erscheint, Effekte, die schon auf dem Screen sind,
werden nicht beeinflu
Spiralen/Spirals: bestimmt, wie stark die Spiral-Effekte vertreten
sind.
Font
nen/Jets: bestimmt, wie stark die Font
nen vertreten sind.
B
lle/Balls: bestimmt, wie stark die Kugeln vertreten sind.
Farb-Font
nen/Color-Jets: bestimmt, wie stark die Mehrfarb-Font
nen ver-
treten sind.
Pixelgeschw./Pixelspeed: Nat
rlich schafft es Fireworks schneller, wenige
Punkte zu zeichnen als viele. Wenn nur wenige
Punkte auf dem Bildschirm sind, mu
Fireworks
deshalb
fter Pausen einlegen, damit die Anzeige
nicht optisch langsamer wird wenn mehr Punkte
hinzukommen. Mit Pixelgeschw. kann man nun ein-
stellen, wie gro
die Pausen bei wenigen Punkten
werden. Hier mu
man einfach etwas herumpro-
bieren, bis der Effekt nicht mehr schneller und
langsamer wird.
CPU-Belastung: Hoch. Speicherverbrauch:110 kB. Programmgr
e:17 kB.
@endnode
@node b_flyingtoasters "Die Blanker in der
bersicht - FlyingToasters"
@{FG Highlight}@{B}FlyingToasters@{FG Filltext}@{UB}
Von Carsten Jahn, Version 1.
Boh ey, guck 'ma da fliegt'n Toaster! Kleine, drollige Wesen mit Fl
und gl
henden Toast-Slots schwingen sich
ber den Screen. Aus leblosen
chenknechten werden niedliche Gestalten, aus dem morgendlichen Fr
werden Hindernisse, schon beginnt der Spa
. Die auf- und abrutschenden
Auswurfhebel erschrecken die Toasts auch nicht, keines springt beiseite.
Folge: jeder 20ste Toaster in Deutschland ist eingeklemmt. Wohin soll das
noch f
hren? Was wei
ich. Spendet jetzt aber nicht f
r eingeklemmte
Toaster, sondern lieber f
r verkohlte Toasts, die haben ein viel schlimm-
eres Leben.
Toaster/Toasters: max. Anzahl der Toasters auf dem Screen.
Toasts: max. Anzahl der Toasts auf dem Screen.
Geschw./Speed: bestimmt die Geschwindigkeit des Blankers.
Marmelade/Jam: schmiert Marmelade, Honig oder Nutella auf die Toasts.
Das perfekte Fr
Double Buffering: schaltet Double-Buffering ein. Dadurch wird das Flackern
der bewegten Objekte vermieden. Ben
tigt mehr Speicher.
Ist dieser nicht vorhanden, wird vor dem Totalabbruch
noch ein Versuch ohne diese Option gemacht.
Leerer Start/Endscreen /
In/Out Moving: Ist diese Option abgeschaltet, so erscheinen die Toasters
und Toasts beim Blankerstart pl
tzlich und sind auch noch
mitten auf dem Screen, wenn der Blanker abbrechen mu
Wird "In/Out Moving" jedoch aktiviert, fliegen die Toasts
und Toasters erst rechts herein, der Blanker beginnt mit
einem schwarzen Bildschirm. Eine den Einstellungen und
Prozessortyp angemessene Zeitspanne vor Ablauf der Dura-
tionzeit werden dann keine neuen Toasts mehr erscheinen,
so da
sich der Blanker auch wieder mit einem leeren
Screen verabschiedet.
Das zeitgem
e Herausfliegen klappt nat
rlich nur bei
aktiviertem "Blanker wechseln/Exchange Blankers", da
sonst der Blanker ja noch bis ins Jahr 3000 laufen k
te.
CPU-Belastung: Hoch. Speicherverbrauch:297 kB. Programmgr
e:29 kB.
@endnode
@node b_glitter "Die Blanker in der
bersicht - Glitter"
@{FG Highlight}@{B}Glitter@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Glitter ist sicher nicht das Genialste, was Ihr jemals gesehen habt,
aber trotzdem ganz nett.
Anzahl/Number: Anzahl der Sterne. Dies verlangsamt den
Start des Blankers, jedoch nicht die Ani-
mation.
Geschwindigkeit/Cyclespeed: Geschwindigkeit des "Glitterns".
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:218 kB. Programmgr
e:15 kB.
@endnode
@node b_memory "Die Blanker in der
bersicht - Memory"
@{FG Highlight}@{B}Memory@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Das ist eine gute M
glichkeit, mal einen Blick in den Speicher des Amiga
zu werfen. Hier werden alle Daten als Grafik abgebildet. So erscheinen
die ge
ffneten Screens und viele andere Dinge, die man nat
rlich nicht
erkennt. Da der Amiga nach einem Reset nicht alle Daten l
scht, sondern
nur zum
berschreiben freigibt, lassen sich oft noch Grafiken eines
zuvor gestarteten Spiels erkennen - nat
rlich in die Bitplanes aufge-
spalten und deshalb zweifarbig. Jedenfalls sieht man immer was Neues...
brigens wird nur das erste MegaByte ChipRAM angezeigt.
Geschwindigkeit/Speed: bestimmt die Geschwindigkeit des Scrollens.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr
e:14 kB.
@endnode
@node b_note "Die Blanker in der
bersicht - Note"
@{FG Highlight}@{B}Note@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Ganz nach Belieben erf
llt Note gleich zwei Aufgaben in einem Blanker:
Einerseits kann den Leuten, die am Computer vorbeigehen oder die etwas vom
Benutzer des Computers wollen, eine Nachricht angezeigt werden. Anderer-
seits ist auch der umgekehrte Weg m
glich, die Anderen k
nnen eine Mittei-
lung eingeben und der Benutzer kann sie lesen. Um die Sache abwechslungs-
reich zum machen, hat Aicke noch drei verschiedene Papier-Typen gezeichnet,
auf denen wird dann geschrieben und angezeigt.
Papier/Paper: Mit diesem Schalter wird der Papier-Typ ausgew
"Granit(e)" ist ein Betonklotz, "Mittelalter/Medival" ist
ein Mittelalter(-Papier nat
rlich...) und "gegen/Against
AIDS" ist gegen AIDS. Anders als Granit(e) und Mittelalter
/Medival ist Against AIDS keine eigene Erfindung, diese
Notizbl
cke gibt's wirklich. Sie sind erh
ltlich bei der
Bundeszentrale f
r gesundheitliche Aufkl
Postfach 910152
5000 K
ln 91 (Sorry - die neue Postleitzahl stand nicht da).
Bestell-Nr. 70551000.
Modus/Mode: Schaltet zwischen dem Empf
nger- und Versender-Modus um. Bei
"Nachricht geben/Give Message" werden die nebenstehenden
Texteingabefelder zur Anzeige eines Textes benutzt. Dabei
mu
jede Eingabe mit <Return> abgeschlossen werden. "Nach-
richt bekommen/Get Message" l
t die Besucher eintippen und
den Benutzer lesen. Wenn "Blanker wechseln/Exchange Blan-
kers" nicht aktiv ist, oder der Blanker noch arbeitet wenn
der Benutzer zur
ckkommt, dann kann er den Text noch lesen.Wenn
aber die Duration-Zeit von Note um war und ein neuer Blanker
gestartet wurde, kann der Benutzer die Nachricht nach dem
Wegklicken des Blanker in der Error-List lesen.
ruhend/Static: Damit sich der Notizzettel nicht in der Phosphorschicht
des Monitors einbrennt, l
t sich mit "Static" die Zeit be-
stimmen, nach der der Zettel wieder seine Position wechselt.
Textzeilen/
Textlines: Dies sind die Schreibfelder. Jedes Schreibfeld steht f
eine Zeile auf dem Notizblatt. Bei Against AIDS k
nnen die
letzten drei Zeilen nicht verwendet werden, weil da unten
Platz fehlt. Auf einer MUI-Oberfl
che haben diese Gadgets
die Shortcuts 1 bis 7 (linke Spalte) und a bis h (rechte
Spalte), c ausgenommen.
Fehlermelungen: Die Nachricht, wenn dies so eingestellt wurde.
erdem die
blichen @{"AMOS-Fehlermeldungen",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:210 kB. Programmgr
e:48 kB.
@endnode
@node b_shuffle "Die Blanker in der
bersicht - Shuffle"
@{FG Highlight}@{B}Shuffle@{FG Filltext}@{UB}
Von Carsten Jahn, Version 1.
Habt Ihr schon einmal einen modularen Screenblanker ohne Shuffle-Modul
gesehen? Ich nicht... Jedoch ist dieser Shuffler erwartungsgem
nicht
ganz gew
hnlich. So wird eine AGA-Workbench unterst
tzt, und mit Grafik-
karten sollte es zumindest mit einem Register- (d.h. nicht Echtfarb-)
Modus keine Probleme geben. Bitte ausprobieren. Au
erdem - und jetzt
kommt der Hammer - shuffled Shuffle den vordersten Screen nicht nur, son-
dern restauriert ihn auf Wunsch auch wieder. Da seid Ihr platt, was?
Modus/Mode: bestimmt den Shuffle-Modus. "Mischen/Shuffle" ist die Stan-
dard-Einstellung. Hier wird der Screen nur geshuffled. Die
beiden anderen funktionieren nur mit aktivierter "Blanker
wechseln/Exchange Blankers"-Option (Hauptfenster), da der
Blanker daf
r wissen mu
, wie lange er maximal blanken soll.
"Mischen & Aufl
sung / Shuffle & Restore" Shuffled die
H
lfte der Zeit, danach wird restauriert, also werden die
Tiles wieder so verschoben, da
alles wieder richtig wird.
"Aufl
sung/Restore" bringt den Screen zuerst (unsichtbar)
so durcheinander, da
nach der eingestellten Zeit der
Screen wie
der hergestellt ist. Danach wird restauriert.
Geschw./Speed: bestimmt die Geschwindigkeit. Diese wird f
r die Zeit-
berechnungen (s.o.) mitber
cksichtigt.
Gitter/Grid: schaltet den 3D-Rahmen ein oder aus. Falls die Farben des
Bildschirms
berhaupt nicht passen (3D-Rahmen w
rde bl
aussehen) benutzt der Blanker nie einen Rahmen.
Fehlermeldungen: "The "Shuffle & Restore" mode and the "Restore" mode can
be only used if "Exchange Blanker" is activated." Diese Fehlermeldung will
uns sagen, da
es doch ein User probiert hat, diese Modi ohne "Blanker
wechseln/Exchange Blankers" zu benutzen.
CPU-Belastung: Niedrig. Speicherverbrauch:??? kB. Programmgr
e:13 kB.
(Der Speicherverbrauch von Shuffle h
ngt sehr stark von der Aufl
sung des
zu "shufflenden" Screens und der Mode-Option ab, da hier etwas mehr Spei-
cherplatz ben
tigt wird.)
@endnode
@node b_skyline "Die Blanker in der
bersicht - Skyline"
@{FG Highlight}@{B}Skyline@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Na Ihr Hinterw
ldler, wollt Ihr mal was anderes sehen als K
he und Berge?
Als Stadtmensch kann ich mir jetzt gar nicht so vorstellen, wie das auf
dem Land abgeht. Zweiunddrei
ig Einwohner, eine Schule, einen Lehrer,
einen Briefkasten, eine Stra
e, eine Telefonzelle, zwei Amigas?
Oder habt Ihr etwa PC's? Doch bevor ich Euch nun
ber die 20 Nachteile
eines PC's aufkl
re, sage ich noch etwas zu Skyline.
Skyline stellt Hochh
user dar, wie sie in richtig gro
en St
dten vorkommen.
Weil es aber dunkel ist, sieht man sie nicht. Man sieht nur die Fenster,
in denen noch Licht an ist. Die Helligkeitswerte f
r die einzelnen Fenster
werden
ber eine quadratische Binominalsublimationsfunktion trianguliert,
die Aicke in n
chtelanger Kleinarbeit nach ihren Koeffizienten aufgel
hatte. Dagegen wird der Mond nur auf einer billigen Parabel bewegt.
Skyline geh
rt zu den Blankern, deren voller Funktionsumfang nicht auf den
ersten Blick ersichtlich ist. Deshalb solltet Ihr hier Duration ruhig ein-
mal hochstellen, dann kommen die vielen Fassadentypen zum Vorschein.
Die verschiedenen D
cher kann man gleich bewundern.
Mond-/Moonphase: Skyline stellt am Horizont einen Mond dar, der sich lang-
sam
ber den Screen bewegt. "Zufall/Random" l
t den
Zufall
ber die Gr
e der Sichel entscheiden, "Ein-
stellung/Setting" macht die Gr
e einstellbar (mittels des
gleichnamigen Sliders darunter).
Einst./Setting: Falls unter Moonphase "Einstellung/Setting" eingestellt
ist, l
t sich hiermit die Gr
e der Mondsichel in Prozent
einstellen. 100% entspricht einem Vollmond, 0% einem Neu-
mond.
Sternfarbe/
Starcolor: Die Sterne am Himmel lassen sich in ihrer Farbe beein-
flussen. "Aus/Off" schaltet sie ganz aus, "Zufall/Random"
l
t den Computer w
hlen.
Anzahl/Number: Anzahl der Sterne.
Y-Limit: gibt an, wie weit die Sterne nach unten gehen bzw. in
welcher Bildschirmzeile sich der unterste Stern befinden
darf.
Himmel/Sky: schaltet zwischen verschieden Copper-Listen im Hinter-
grund um. "Zufall/Random" ist wieder der Zufallsgenerator.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:200 kB. Programmgr
e:32 kB.
@endnode
@node b_soccer "Die Blanker in der
bersicht - Soccer"
@{FG Highlight}@{B}Soccer@{FG Filltext}@{UB}
Von Carsten Jahn, viele Spieler-Grafiken von Aicke Schulz; Version 1
Hier mal wieder eine echt innovative Idee: Fu
ball in den Arbeitspausen
hat wohl vielen gerade noch gefehlt. Was Bundesliga-Fans bestimmt begei-
stert, wird wohl auch anderen (mich eingeschlossen...) viel Freude machen.
Die kleinen Fu
baller rennen, was das Zeug h
lt (jedenfalls auf schnelle-
ren Amigas), um die gegnerische Mannschaft fertigzumachen.
Ab und zu f
llt auch mal ein Tor, mangels Sound ist aber leider nicht
viel von den Fans zu h
ren. Und hier haben wir auch schon die Aufgabe f
Euch da drau
en: anfeuern, mitjubeln, ausrasten. Viel Spa
damit.
Wenn m
glich (Speicher verf
gbar) arbeitet Soccer mit Double Buffering.
Aufstellung Wei
/Rot /
Line-up White/Red: hiermit stellt Ihr die Spieltaktik ein, nach der
die kleinen Erdnuckel spielen.
1. Zahl: Spieler in der Abwehr,
2. Zahl: Spieler im Mittelfeld,
3. Zahl: Spieler im Sturm.
Torwartsintelligenz/
Keeper intelligence: als ob irgendetwas im Computer intelligent w
l
t sich hier die Intelligenz der beiden Torw
einstellen, was die Ergebnisse nat
rlich fatal
beeinflu
CPU-Belastung: Hoch. Speicherverbrauch:378 kB. Programmgr
e:45 kB.
Bei Speichermangel:260 kB.
@endnode
@node b_stars "Die Blanker in der
bersicht - Stars"
@{FG Highlight}@{B}Stars@{FG Filltext}@{UB}
Von Carsten Jahn, Version 2
Auch hier ein Blanker, der dem Beobachter den Eindruck gibt, r
umlich
in einem unendlichen Weltraum herumzufliegen. Auch hier ein paar Extras:
re zuerst der R
rtsgang zu nennen, den viele schon in anderen
Star-Blankern vermi
t haben werden. Der absolute Clou ist aber der Dreh-
Effekt, der sich in H
ufigkeit, Beschleunigung und Geschwindigkeit
beeinflussen l
t. Besonders der "Waschmaschinen-Effekt" (hohe Drehzahl
bei niedriger Geschwindigkeit) l
st immer wieder
belkeit unter den
Betrachtern aus...
rrah!
Fast schon be
ngstigend wirken die Shift-Effekte: die Kamerafahrt durchs
Sternenfeld ist dann
erst kurvenreich.
Diesen Blanker habe
brigens optimiert wie keinen anderen. Besonders die
Dreheffekte verlangsamen den Blanker kaum, und die Performance insgesamt
ist schon ganz gut. Wie jeden anderen Blanker habe ich die Stars zwar in
C geschrieben, aber mit Hilfe des Compiler-Assembler-Listings optimiert.
Anzahl der Sterne/
Number of Stars:
h.. Anzahl der Sterne?
Normale Bewegungen/Normal Movements (Bewegungen auf der Z-Achse):
Maximum: max. Fluggeschwindigkeit des Betrachters.
Manimum: min. Fluggeschwindigkeit des Betrachters. Negative
Zahlen lassen auch den R
rtsgang zu.
ndern/Changes: bestimmt, wie oft die Geschwindigkeit gewechselt wer-
den soll.
Start: Startgeschwindigkeit.
Drehungen/Turns (Bewegungen UM die Z-Achse, Drehungen des Betrachters):
Maximum: max. Drehmoment.
Beschleunigung/
Acceleration: Beschleunigung der Drehung.
ndern/Changes: bestimmt, wie oft die Drehrichtung wechselt.
Start: Startgeschwindigkeit.
Verschiebungen/Shifts (Bewegungen der X- und Y-Achse)
Geschw./Speed: Dieser Wert legt fest, wie eng die Kurven sind.
Gebrauch/Usage: bestimmt, wie oft der "Kurvenmodus" verwendet wird;
0 = nie, 10 = immer.
X/Y: Hiermit wird definiert, ob sich die Verschiebungen
nur auf eine Achse, beide oder gar keine beziegen.
CPU-Belastung: Hoch. Speicherverbrauch:70 kB. Programmgr
e:11 kB.
@endnode
@node b_softwarefailure "Die Blanker in der
bersicht - SoftwareFailure"
@{FG Highlight}@{B}SoftwareFailure@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Tipp, tipp; F10; Compiling; No Errors; Linking; Running: Blink-Blink-Blink.
-Zap- "Software Failure - Press left mouse button to continue".
Von erfolgreichen Programmieren empfohlen: der leichte Absturz f
Zwischendurch. In H
llen ist auch das Sechserpack geeignet. F
r An-
wender, die nur ausgereifte Software benutzen, bietet sich aber Software-
Failure f
r den t
glichen Gebrauch an. SoftwareFailure simuliert den
komplexen Ablauf eines Absturzes nur grafisch, was aber den Vorteil hat,
man nach dem Blanken weiterarbeiten kann.
berraschungseffekt nach den Arbeitspausen ist immer wieder t
dlich!
Damit sich die Alert-Box aber nicht einbrennt, und damit Nervenschwache
nicht jedesmal einen Infarkt bekommen, wird der SoftwareFailure noch in
drei verschiedenen Modi animiert.
Effekt/Effect: Mit Effekt kann gew
hlt werden, was nach einer gewissen
Zeit des Blinkens mit der Alert-Box geschehen soll:
"Zerflie
en/Melt" l
t sie langsam zerflie
en, "Springen/
Bounce" l
t sie auf und ab h
pfen und "Crazy" bewegt die
einzelnen Buchstaben.
Warten/Wait: Hier wird die gewisse Zeit (s.o.) bestimmt, in Sekunden.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:150 kB. Programmgr
e:29 kB.
@endnode
@node b_thunder "Die Blanker in der
bersicht - Thunder"
@{FG Highlight}@{B}Thunder@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Blitz und Donner im Amiga! Mit realistischem Sound. Wenn es drau
en kalt
und Winter ist (kann man das so sagen?...), dann kommt dieser Blanker ge-
rade richtig. Die Blitze zucken nur so
ber den Screen, da
man denkt,
es hat den Monitor zerbr
selt. Au
erdem kann man sehr gut die
bertra-
gungsgeschwindigkeit von Wellen mit unterschiedlicher Wellenl
nge in der
Luft erkennen: w
hrend man den Blitz fast sofort sieht, kommt das Ge-
usch erst sp
ter. Wie lange die Zeitspanne zwischen Blitz und Donner
ist, h
ngt also von der Entfernung des Unwetters ab, die man mit "Distanz/
Distance" einstellen kann.
Einschl
ge/Flash Interval: Mit dieser Einstellung wird bestimmt, wie oft
die Blitze einschlagen. Es sind jeweils Zeit-
spannen angegeben, die Blitze werden dann in
der gew
hlten Zeitspanne abgeblitzt.
Distanz/Distance: Gibt die Entfernung des Gewitters in Metern an
und bestimmt damit die Zeitspanne zwischen
Blitz und Donner.
Toneffekt/Sound: Hiermit kann man die Ger
usche abschalten,
falls man das mit den Wellenl
ngen noch nicht
ganz verstanden hat.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:185 kB. Programmgr
e:32 kB.
@endnode
@node b_waves "Die Blanker in der
bersicht - Waves"
@{FG Highlight}@{B}Waves@{FG Filltext}@{UB}
Von Carsten Jahn, viele Farbpaletten von Aicke Schulz; Version 1.
Dieser Blanker erzeugt Wellen, die so aussehen, als w
ren sie einem
ganz genialen Algorithmus entsprungen. Tats
chlich wird nur ein einfacher
Trick angewandt, wie er in manchen Demos zu finden ist. Zum besseren Ver-
ndnis und zum allgemeinen Aha-Effekt will ich ihn erl
utern: Zuerst wird
(im Hintergrund) mit 1, 2 oder 3 Pixel dicken Querstreifen ein Farb-
verlauf auf den Screen gezeichnet. Dann kommt eine Sinus-Funktion daher,
die aus den Streifen eine Welle macht - hoch, runter, hoch runter, ...
Weil das Ergebnis noch eindeutig als Sinus-Funktion erkennbar w
re, wird
jede Bildzeile noch um eine weitere Sinus-Funktion nach links oder rechts
verschoben. Jetzt bekommt der Screen seine Farben, die kontinuierlich
durchlaufen. Zur Steigerung des beliebten W
rg-Effekts wird der Screen,
der Anfangs mit
bergr
ffnet wurde, anhand zweier Sinus-Funktionen
(ach ja..) nach links/rechts und oben/unten verschoben. Nat
rlich kann
man keine gew
hnliche Farbpalette nehmen, sie mu
echt terrorm
ig 'rein-
hauen. Da bleibt kein Teppich trocken -schluck-.
Obwohl auch bei diesem Blanker eine Duration-Einstellung bis 30 min.
glich ist, empfehlen wir aus gesundheitlichen Gr
nden nicht mehr als
6 Minuten. Ob die Krankenkassen f
r Folgesch
den zahlen, ist uns nicht
bekannt. Nebenwirkungen und Gegenanzeigen bitte melden.
Das Prefs-Fenster ist in zwei Bereiche aufgeteilt. Links findet Ihr die
Farbpaletten. Waves w
hlt eine aus, bei der das H
kchen gesetzt ist. Wer
hinterh
ltigerweise alle H
kchen l
scht, wird mit einer Zufallspalette
nicht unter 32 Farben bestraft. Auf der rechten Seite seht Ihr die Ein-
stellungen zum Zeichnen der Waves:
Wellengr
e/WaveSize: beeinflu
t die gesamt-Dicke der Waves.
XWellen/XWaves: bestimmt die Breite der Waves. Kleiner Wert = breite
Waves.
YWellen/YWaves: bestimmt die H
he der Waves. Kleiner Wert = hohe
Waves.
XGr
e/XSize: ist der Maximalausschlag der horizontalen Sinus-
Funktion.
YGr
e/YSize: ist der Maximalausschlag der vertikalen Sinus-
Funktion.
XGeschw./XSpeed: legt fest, wie schnell sich der Screen in X-Richtung
bewegt.
YGeschw./YSpeed: legt fest, wie schnell sich der Screen in Y-Richtung
bewegt.
Da jetzt sicher nicht jeder Parameter sonnenklar ist (irgendwie kann man
die Waves ja auch nicht beschreiben) rate ich zum gr
ndlichen Auspro-
bieren.
brigens sind manche Farbpaletten bewu
t NICHT sch
n, sondern
dienen dem Abschrecken von diversen Haustieren. Denn Vogelsch***e auf der
Tastatur ist eine recht unangenehme Sache; Katzen haaren alles voll und
Hunde lutschen glatt die Leertaste weg. Also Vorsicht!
brigen halte ich gar nichts von Pa
wortprogrammen, die den Computer
vor Fehleingaben durch
ber alles trampelnde Katzen sch
tzen. Ein Pa
wort h
lt doch keine Katze davon ab, alles zu verw
sten!)
CPU-Belastung: Niedrig. Speicherverbrauch:212 kB. Programmgr
e:14 kB.
@endnode
@node b_worldtime "Die Blanker in der
bersicht - Worldtime"
@{FG Highlight}@{B}Worldtime@{FG Filltext}@{UB}
Von Aicke Schulz, Version 1.
Wie h
ngt man eine Weltkarte auf, ohne sich die Finger am Kartenst
zu klemmen? Ganz einfach: entweder man l
t die Karte weg und benutzt den
Amiga (Buuuh) oder man h
ngt die Karte mit dem NEUEN, GROSSEN, PRAKTISCHEN,
PASSGENAUEN @{B}SCHLONZ-Kartenaufh
ngehandschuh@{UB} auf! (Yeah).
Der @{B}Schlonz-Arbeitshandschuh@{UB} wurde EXTRA F
R SOLCHE AUFGABEN ENTWICKELT
und bietet OPTIMALEN TRAGEKOMFORT. Wir haben uns in einer Berliner Droge-
riefiliale umgesehen. Ah, da ist ja schon der erste Kunde. Interessiert
bleibt er vor dem @{B}Schlonz@{UB}-Warensortiment stehen. Eine FREUNDLICHE Ver-
uferin hilft ihm sogleich: "F
r welche Aufgabe ben
tigen Sie denn Ihren
nftigen @{B}Schlonz@{UB}-Qualit
tshandschuh? Ich habe doch gleich gemerkt, da
Sie sich SPONTAN f
r eines der @{B}Schlonz@{UB}-Produkte entschieden haben!" - "Ja,
ein @{B}Schlonz@{UB}-Produkt wollte ich schon kaufen, da wei
ich schlie
lich, da
ich QUALTIT
T bekomme. Aber spontan ist meine Entscheidung nicht, mein
NACHBAR hat mir @{B}SCHLONZ@{UB} EMPFOHLEN. Ich suche einen @{B}Schlonz@{UB} f
r's Karten-
ngen. Wo ist der nur, f
hren Sie den etwa nicht?" - "SELBSTVER-
NDLICH f
hren wir das gesamten @{B}Schlonz@{UB}-Sortiment. Der zum Kar-
tenaufh
ngen ist im Moment DER RENNER. Welche Gr
e haben Sie denn?" -
"XL." - "Flupp, da ist er schon. Wollen Sie GR
N oder ROT?" - "Tjaaa,
schwere Frage. Ich glaube, zu den Karten pa
t der gr
ne @{B}Schlonz@{UB} am
besten." - "Gute Wahl. Dieser @{B}Schlonz@{UB} wird ihnen noch SEHR LANGE Freude be-
reiten. Auf Wiedersehen!" F
r die User, denen die 2,5m x 1.7m - Karten zu
bersichtlich sind, gibt's aber zum Gl
ck noch andere Alternativen zu
unserem @{B}Schlonz@{UB}-Schrott. Einfach Worldtime starten. Als kleiner Gag mit
GROSSER Wirkung zeigt der @{B}Amiga@{UB} auch noch die Uhrzeiten in den entlegensten
dten an.
Reihenfolge/Order: "Random" zeigt die St
dte nach dem Zufallsprinzip an,
"One after another" in alphabetischer Reihenfolge.
Warten/Wait: bestimmt, wie lange eine Stadt angezeigt wird (in Se-
kunden).
Stunden, Minuten,
Hours und Minutes: ver
ndert die Zeitverschiebung geben
ber der MEZ.
F
r Deutschland m
t Ihr 0 und 0 einstellen, weil
sich Deutschland voll in Mitteleuropa befindet.
Sprache/Language: Hiermit kann man das Datumsformat umschalten.
F
r Deutschland m
t Ihr "Deutsch" einstellen.
Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}.
CPU-Belastung: Niedrig. Speicherverbrauch:290 kB. Programmgr
e:51 kB.
@endnode
@node errors "Fehler m
ssen sein."
Jeder, der auch nur ein noch so kleines Programm in einer nicht-BASIC-
Sprache geschrieben hat, wei
, was beim Programmlauf alles falsch gehen
kann. Praktisch jede Funktion des Betriebssystems liefert einen R
gabewert, der dann eventuell signalisiert, da
kein Ergebnis vorliegt.
Und ein korrektes Programm soll schlie
lich mehr ausgeben als
"Fehler: Programmabbruch."
Und bei Madhouse k
nnen zus
tzlich die Blanker einen Fehler zur
cklie-
fern, der dann von Madhouse angezeigt werden mu
Tritt ein Fehler bei einem Blanker auf, und er wurde im BlankerPrefs-
Fenster gestartet, zeigt Madhouse den Fehler unten im Blanker-Prefs-
Fenster an, welches daf
r "ausgeklappt" wird.
Stellt aber der Blanker einen Fehler fest, nachdem er durch Madhouse
gestartet wurde (nach Ablauf der Zeitspanne), merkt sich Madhouse erst
den Fehler, und ruft ggf. einen anderen Blanker auf. Ist keiner der
ausgew
hlten mehr
brig (oder ben
tigen die verbliebenen im Moment zuviel
CPU-Performance, siehe @{"Advanced Options Fenster, 4.", link adv_op}) wird nur
ein schwarzer Bildschirm angezeigt. Nach Abbruch eines Blankers / des
schwarzen Bildschirms mit Maus oder Tastatur und evtl. Eingabe des Pass-
worts wird dem erstaunten Benutzer die @{B}Madhouse-ErrorList@{UB} pr
sentiert.
Hier werden alle aufgetretenen Fehler gelistet. Verlassen wird die Liste
mit dem Schlie
gadget.
Zu den Blanker-spezifischen Fehlern, die nichts mit so profanen Dingen
wie "Out of memory", "Couldn't open Screen/Window" (beide Fehler sind das
Resultat von zuwenig Speicher) zu tun haben, findet sich die Erl
uterung in
@{"Alle Blanker in der
bersicht", link blankers}.
In diesem Kapitel m
chte ich aber noch die Fehler von Madhouse darlegen,
die nicht sofort verst
ndlich sind (also lasse ich die "Cannot open Win-
dow"- und "Couldn't write file"-Fehler weg.
Wenn der MadhouseConfigEd oder Madhouse selbst einen Fehler anzeigt,
tut es das mit einem Fenster auf der Workbench, welches ein Abort-Gadget
besitzt. Um das gleich klarzustellen: Dieses Fenster ist ein Easy-Request!
Wer mit der Bedienung des Gadgets nicht ganz klarkommt, der darf sich ruhig
fragen, wie wohl ein Difficult-Request funktioniert...
In beiden F
llen wird der Fehlertext angezeigt. Uuuund jetzt geht's los:
@{B} Bitte einen KOMPLETTEN Pfad ausw
hlen,...
Please select a COMPLETE path,...@{UB}
r bestimmte Spezialit
ten (Buffering) ben
tigt Madhouse den Namen der
Diskette/Festplattenpartition, auf der sich die Blanker befinden. Das
liegt ganz einfach daran, da
man nicht abfragen kann, ob z.B. "DF0:" oder
"//Blankers" gerade im Laufwerk liegt... Das geht nur mit Pfaden wie
"MadhouseDisk:" oder "MadhouseDisk:Blankers". Also bitte etwas entsprechen-
des im Path-Gadget des Hauptfensters eintragen.
@{B} Die "gadget"-Datei von xy enth
lt keinen BlankerInfo-Chunk!
BlankerInfo-Chunk does not exist!@{UB}
Die Datei "gadget" des betreffenden Blankers (in seinem Verzeichnis) ist
fehlerhaft; die BlankerInfo-Informationen fehlen. Madhouse kann nicht
lesen, ob der Blanker viel CPU-Performance benutzt oder nicht.
@{B} Unbekanntes Makro: "xx"!
Unknown macro: xx@{UB}
In der "gadget"-Datei des aufgerufenen Blankers befindet sich ein Makro
namens xx. Dieses ist leider nicht existent.
@{B} Couldn't get a lock on this directory!@{UB}
Vermutlich wurde im Path-Gadget oder mit dem FileRequester ein falscher
Pfad eingegeben. Oder ein Diskettenkopierer hat die gesamte Disk gesperrt,
so da
Madhouse nicht darauf zugreifen kann.
@{B} Konnte das Verzeichnis "RAM:Madhouse_Storage" nicht anlegen.
Couldn't create the subdirectory "Ram:..."@{UB}
r verschiedene Zwecke wird ein Unterverzeichnis "Madhouse_Storage" in der
RAM: - Disk angelegt. Das geht aber nur, wenn 1. Ram:
berhaupt gemounted
ist (Normalzustand) und wenn 2. Madhouse nicht bereits gestartet wurde.
So wird auch eine Doppelt-Inkarnation von Madhouse verhindert.
@{B} Madhouse wurde doppelt gestart! Soll es beendet werden?
You started Madhouse the second time. Do you want to remove it?@{UB}
So ein Schlingel: Madhouse doppelt gestartet und gedacht, jetzt kommt alles
durcheinander, oder was? Nur, damit Ihr im Bilde seid:
- Das Madhouse, da
Ihr eben gestartet habt, hat sich sowieso schon beendet.
- Das Madhouse, da
Ihr vorhin gestartet habt, hat hinterh
ltigerweise da-
von erfahren. Und nun? Naja, der Doppelstart ist eine M
glichkeit, Mad-
house loszuwerden. Einfach den Requester mit "Remove Madhouse" beantwor-
ten, und tsch
. "Do nothing" sieht den Doppelstart eher als einen Un-
fall an und macht so weiter wie zuvor.
@{B} Die amos.library wurde nicht gefunden...
No amos.library@{UB}
Selbstredend ben
tigt Madhouse nicht die amos.library, um Himmels Willen!
Madhouse wollte die amos.library von LIBS:amos.library in sein Storage-
Verzeichnis auf der Ram:-Disk kopieren. Damit die Blanker vollen Zugriff
darauf haben. Die Datei LIBS:amos.library war aber nicht vorhanden, was
zur Folge hat, da
der Buffering-Modus ausgeschaltet wird. Jetzt solltet
Ihr lieber keine AMOS-Blanker (die von Aicke, siehe Blanker-Teil) starten,
denn die werden die amos-lib erst recht nicht finden k
nnen, und dann ist
. Madhouse wurde offenbar falsch installiert.
@{B} Konnte die "gadget"-Datei des Blankers "xy" nicht laden!
Couldn't load the "gadget"-file!@{UB}
Die gadget-Datei wird ben
tigt, um das Fenster zu
ffnen. Sie ist nicht
vorhanden. Diese Datei mu
ebenfalls vorhanden sein, damit Madhouse beim
Einlesen des Blankers-Verzeichnisses Informationen zu diesem Blanker
erhalten kann.
@{B} Probleme mit dem Pa
Problems with your password@{UB}
Dieser Fehler erscheint, falls es jemandem nicht m
glich war, sein Pa
wort bei der Sicherungsabfrage einzutippen. Das kann jetzt verschiedene
nde haben...
Angenommen, Ihr habt es vergessen (nach 2 Sekunden...), dann sollte ein
anderes gew
hlt werden. War der Eingabebildschirm auf einmal weg? Tjaa,
wer hat denn da <Ctrl>, <Alt>, <Caps Lock> oder
hnliches gedr
ckt? Aus
Sicherheitsgr
nden wird bei diesen Qualifiern abgebrochen (stimmt
wirklich; damit man NICHT einen Trick anwenden kann, den ich aber trotzdem
nicht verrate - doppelt sicher!). Die Ziffern und Sonderzeichen, die nicht
mit o.a. Zeichen erreicht werden m
ssen, gehen aber.
@{B} Madhouse ben
tigt einen Stack von mindestens 4.096 Bytes! ...
Need a stack minimum of 4.096!@{UB}
Der Stack ist ein Bereich im Speicher des Amiga, der f
r jedes Programm
bei seinem Start von AmigaDOS reserviert wird. Das gestartete Programm
hat keinen Einflu
auf dessen Gr
e, weil er kurz vor dem Start des
Programms eingerichtet wird.
Die ben
tigte Gr
e von 4096 Bytes ist bei Amiga-Programmen eigentlich
der Standard, deshalb sollte man Madhouse von
berall her aufrufen
nnen. Falls dieser Fehler trotzdem auftritt, erkl
re ich Euch nun, wie
man die verschiedenen Programme doch dazu
berreden kann, Madhouse
korrekt zu starten.
Die Workench merkt sich die Stack-Gr
e der Programme in ihrem Icon.
Also Madhouse 1x anklicken und im "Icon"- bzw. "Piktogramm"- Men
Workbench "Information" ausw
hlen. Ein Fenster
ffnet sich, in dem sich
auch ein Number-Gadget namens "Stack:" befindet. Hier 4096 eintragen
und mit "Save" bzw. "Speichern" verlassen.
Die Shell startet ihre Programme immer mit dem aktuellen Stack, der
r jedes Shell-Fenster variieren kann. Also Shell
ffnen, "stack 4096"
eingeben und Madhouse mit z.B. "run Work:Madhouse/Madhouse" starten.
Wer Madhouse mit dem Toolmanager startet, der findet im
ndere Programm-
Objekt-Fenster auch hier ein Stack-Gadget.
@{B} Bug #1 in program!@{UB}
Bitte schreibt mir, wenn dieser Fehler auftritt!!
@{B} Auf deiner 1.3-Sch
ssel l
uft Madhouse nicht!@{UB}
-Schluck!- ist dies etwa ein 1.x-Amiga?!
Ey Leute, es gibt doch wirklich f
r JEDES Amiga-Modell eine Kickstart-
stung auf 2.0!! 93% aller PD-Software, die ich benutze, braucht
OS 2.0! Und jedes 3. kommerzielle Programm auch! Wie kann man es auf dem
Amiga ohne OS 2.0 aushalten, wenn man nicht nur spielt? OS 2.0 ist soooo
toll und vergleichsweise billig!
r pure Einsteiger, die vor ein paar Monaten ihren Amiga gekauft haben:
OS 2.0 hei
t das Betriebssystem, und Euch hat man einen Amiga ange-
dreht, der nicht mal auf dem Stand von vor 5 Jahren ist. Besorgt Euch
also das Upgrade. OS hat nichts mit IBM zu tun :-> sondern ist von Commo-
dore.
Wer meint, OS 2.0 zu haben und bekommt diesen Fehler, der hat ein echtes
Problem...
Wer gerade losrennen will, um OS 2.0 zu kaufen, der kann sich auch gleich
das aktuellere 3.1 besorgen.
@{B} Die "gadget"-Datei dieses Blankers kann nicht gelesen werden. Dazu
wird eine neuere Madhouse-Version ben
tigt.
Cannot read the "gadget"-file of this blanker! (You need a newer Version
of Madhouse)@{UB}
Die erste Zeile der "gadget"-Datei dieses Blankers hat nicht den Inhalt
"Madhouse, Blankerwindow-Def V1". Entweder Schreibfehler oder Eure Mad-
house-Version ist
berholt. (Ich denke nicht, da
ich am Dateiaufbau mal
ndern werde. Wenn neue Chunks hinzukommen, ist das noch lange kein
Grund, da
die alten Files inkompatibel werden m
ssen - dazu habe ich
mir das ja extra so ausgedacht.)
@{B} File mismatch: Chunk "Dimensions" must be the first chunk!@{UB}
Dieser Chunk mu
der vor allen anderen Chunks stehen!
@{B} BlankerPrefs-window too big for this screen!@{UB}
Die Workbench ist zu klein f
r diese Prefs-Fenster. Oder Schreibfehler
in der "gadget"-Datei dieses Blankers (Stichwort "CHUNK:WINDOW").
@{B} Enter a higher value in "CHUNK:DIMENSIONS" - Gadgets!@{UB}
Nicht nachdenken, ... machen!
@{B} Der Chunk MUI-PREFSORDER ist falsch.
Wrong Statements in CHUNK:MUI-PREFSORDER.@{UB}
Im Chunk "MUI-PREFSORDER" stehen falsche Sachen drin.
@{B} Konnte den Config-Editor nicht erreichen.
Couldn't access the Config-Editor.@{UB}
Madhouse wollte den MadhouseConfigEd starten, also das Programm, mit dem
man die Madhouse-Einstellungen
ndern kann. Damit Madhouse den ConfigEd
starten kann, mu
chst Madhouse wieder beendet werden, da die Pfad-
angabe zum ConfigEd nur beim Programmstart ausgelesen wird.
Um Madhouse zu beenden, mu
man zun
chst wissen, ob es
berhaupt l
- Wenn Madhouse gerade erst seit wenigen Sekunden l
uft und man nicht
"Madhouse" im Tools/Hilfsmittel-Men
aufgerufen hat, und diese Meldung
erscheint, dann mu
sich Madhouse sowieso sofort nach Best
tigung des
Requesters beenden, da es ohne Einstellungen keine Chance hat.
- Wurde diese Meldung durch die Auswahl von "Madhouse" im Tools/Hilfs-
mittelmen
"provoziert", dann lagen offenbar schon die korrekten Ein-
stellungen vor. Madhouse mu
nun beendet werden. Dies kann
ber das
Exchange-Programm oder durch den erneuten Programmstart und an-
schlie
endem "Remove Madhouse" geschehen.
Ob sich Madhouse nach diesem Requester beenden mu
, ist auch dem Requester-
Text zu entnehmen, der auf diese Situation angepa
t wird. Ob Madhouse
gerade l
uft oder nicht, l
t sich jederzeit einfach durch einen Blick
ins Tools-Men
feststellen.
Nun sollte man im ToolType "CONFIGED" von Madhouse den Pfad und Namen des
ConfigEds eintragen.
Will man Madhouse nicht mit der Workbench, sondern von der Shell starten,
so wird der ConfigEd im Programmverzeichnis von Madhouse angenommen. In
diesem Fall k
nnen die ToolTypes meines Wissens nach nicht ausgelesen
werden.
@{B} Der MadhouseConfigEd kann nur von Madhouse selbst gestartet werden.@{UB}
Klare Sache: der ConfigEd l
t sich nur
ber das Hilfsmittel- / Tools-Men
der Workbench starten, nicht direkt durch den User. Diese Einschr
nkung
te sein, da Madhouse und der ConfigEd beide das Madhouse_Storage-
Verzeichnis in der Ram-Disk benutzen. Wenn beide gleichzeitig laufen oder
Madhouse nicht gestartet wurde, kann es zu Kollisionen kommen.
@endnode
@node amos_errors "Die AMOS-Pro-Fehlernummern und ihre Bedeutung"
Dieses Kapitel beschreibt die Fehlernummern, die von den AMOS-Blankern
angezeigt werden, wenn etwas nicht klappte. (Dieses Kapitel kann nur
aus den Blanker-Beschreibungen der AMOS-Blanker abgerufen werden, des-
halb k
nnt Ihr Euch jetzt sicher sein, da
der Blanker ein AMOS-Blanker
ist.)
Zuerst mu
noch gesagt werden, da
ein bestimmter Fehler nicht als Nummer,
sondern als Klartext in der Errorlist / im BlankerPrefs-Fenster angezeigt
wird. Er lautet "@{B}Out of memory.@{UB}" und signalisiert, da
nicht ge-
gend freier Speicher zur Verf
gung stand, um den Blanker zu starten.
In den anderen AMOS-Fehlern steht etwas von einer AMOSPro-Errornumber, und
diese Numbers bekommen gleich eine Bedeutung. Da jedoch das AMOS-Pro-Hand-
buch 13 Seiten
ber dieses Thema enth
lt, z
hle ich hier nur die Fehler
auf, die sich von Euch beheben lassen.
@{B}Nummer Beschreibung@{UB}
@{FG Highlight} 30 Falsches IFF-Format.@{FG Filltext} Vielleicht konnte man diesem Blanker den
Dateinamen eines Bildes
bergeben, das er laden sollte. Diese
Bilddatei ist jedoch in Wirklichkeit eine Datei anderen Typs.
@{FG Highlight}187 Kann die med.library nicht laden.@{FG Filltext} Dieser Blanker wollte wohl Musik
abspielen, und ohne med.library geht das (fast) nicht. Keiner
von Aickes AMOS-Blankern ben
tigt diese Library, weshalb sie auch
nicht in Madhouse enthalten ist.
@{FG Highlight} 32 Das IFF-Bild pa
t nicht auf den Bildschirm.@{FG Filltext} Eigentlich ein Fehler
wie Nummer 30, an Eurem Bild stimmt etwas nicht.
@{FG Highlight} 86 Ger
t (=Diskette) nicht verf
gbar.@{FG Filltext} Auch diese Fehlermeldung kann
nur von einem Blanker kommen, der die Eingabe eines Dateinamens
erlaubt. Ohne Buffering darf man hier den gesamten Pfad eingeben,
weil dann die Diskette (h
chstwahrscheinlich die Festplatte) immer
"eingelegt" sein mu
. Mit Buffering mu
man seine Datei in das Un-
terverzeichnis des Blankers kopieren und nur den Dateinamen ange-
ben. Wenn das so geschehen ist, arbeitet der Blanker nicht nach
der Madhouse-Konvention aus @{"Das Blanker-Unterverzeichnis", link p_dir }.
@{FG Highlight}101 Diskettenfehler.@{FG Filltext} Hier ist wohl die Diskette/Festplatte mehr oder
weniger kaputt.
@{FG Highlight} 88 Diskette voll.@{FG Filltext} Dieser Fehler kann eigentlich nur entstehen, wenn ein
AMOS-Blanker gerade seine Fehlermeldung in RAM:Madhouse_Storage ab-
legen wollte. Der Speicher ist wohl so knapp, da
selbst eine kleine
Datei nicht mehr in den Speicher pa
t. Vermutlich ist der Speicher
dann auch so knapp, da
Madhouse diesen Fehler gar nicht anzeigen
kann. Und dieser Fehler kann ja auch nur
ber die RAM:-Disk an Mad-
house
bermittelt werden. Also ist DAS hier der Fehler und nicht
irgendein anderer, der diesen Fehler ausl
ste. Ein Fehler, der nur
beim Schreiben eines anderen Fehlers auftritt, mu
hier eigentlich
nicht mehr erw
hnt werden. So einen Fehler darf man ja eigentlich
noch nicht einmal abfragen, oder habt Ihr eine Ahnung, was passiert,
wenn beim Schreiben des Fehlers ein Schreibfehler auftritt, der dann
auch geschrieben wird und sicherlich seinerseits den n
chsten
Schreibfehler verursacht?!
Ach, verge
t es.
Tats
chlich gibt es auch hier den Sonderfall 48d (siehe Problem-
kapitel) mit der statischen Ram-Disk als RAM:. Falls Eurer Stat-Ram
also gerade das letzte Byte allegegangen ist, (bei den Typen, bei
denen man den max. Speicherverbrauch angeben kann/mu
), dann ist
ist dieser Fehler auch hier m
glich.
@{FG Highlight} 81 Datei nicht gefunden.@{FG Filltext} Entweder habt Ihr eine Datei gel
scht, die der
Blanker unbedingt ben
tigt, oder Ihr habt Euch bei einem eigenen
Dateinamen vertippt.
@{FG Highlight} 44 Font (Schriftfamilie) nicht verf
gbar.@{FG Filltext}
@{FG Highlight} 31 IFF-Kompressionsalgorithmus unbekannt.@{FG Filltext} Abhilfe: Die eigene IFF-Datei
in ein Malprogramm laden und gleich wieder unter demselben Namen
abspeichern. Diesen Vorgang mit allen zur Verf
gung stehenden Mal-
programmen und Bildbearbeitungen wiederholen, bis der Fehler nicht
mehr auftritt.
@{FG Highlight} 82 Buchstabensalat im Dateinamen.@{FG Filltext} Da hat sich einer m
chtig vertippt,
denn dieser Dateiname pa
t noch nicht einmal von Format her zu
AmigaDOS. (Beispiel: "Work:Bla:Hallo")
@{FG Highlight} 93 Keine Diskette im Laufwerk.@{FG Filltext} Siehe Fehler 86.
@{FG Highlight} 92 Keine AmigaDOS-Diskette.@{FG Filltext} Wirkung wie 101.
@{FG Highlight}186 Kein Tracker-Modul.@{FG Filltext} Hier konnte man wohl den Dateinamen eines Noise-
Tracker-kompatiblen Musikmoduls angeben. Diese Datei ist nicht kom-
patibel.
@{FG Highlight} 0 Kein freier Raum im Stack mehr.@{FG Filltext} Abhilfe: in einem Editor (z.B. c:ed)
die "gadget"-Datei laden, die im Verzeichnis des Blankers steht, der
den Fehler verursacht hat. In der Datei nach einem Text
"CHUNK:BLANKERINFO" suchen. Vier Zeilen darunter befindet sich eine
gro
e Zahl, z.B. 5000. Daraus jetzt z.B. 9000 oder mehr machen.
Die ver
nderte Datei abspeichern und das Madhouse-Hauptfenster
ffnen. Jetzt in das Path-Gadget klicken und <Return> dr
cken. Nun
sollte der Blanker funktionieren, wenn nicht, die Zahl noch gr
w
hlen.
Ein Versuch mit absichtlich zu niedrigem Stack zeigte, da
der Blan-
ker zwar tolle Probleme (recoverable Alert, Mauszeiger bleibt ste-
hen) verursacht, aber nicht diesen Fehler erzeugt. Trotzdem ist dann
die Vorgehensweise richtig, um einen eigenen Blanker zum Laufen zu
bringen.
@endnode
@node buffering "Alles
ber die Buffering-Option!"
Da h
ngt nun so ein kleiner Haken im Advanced-(Options-Fenster) rum...
was kann der schon machen? Und wer ihn einfach ausprobiert, wird auch
kaum etwas merken. Doch der unscheinbare Haken ist ein starker Vorteil
r jeden, der die Blanker auf eine Diskette installiert hat.
Denn man kann eine Diskette bekanntlich aus dem Laufwerk nehmen.
Wenn dann ein Programm darauf zugreift, erscheint ein Requester, der
Euch freundlich auffordert, diese Disk einzulegen. W
hrenddessen ist das
aufrufende Programm praktisch "leblos".
Das Dilemma: Den meisten Programmen ist es egal, ob sie ihre Disk nun
gleich oder ein paar St
ndchen sp
ter kriegen. Madhouse nicht, denn wenn
geblankt werden mu
, dann gleich.
Also wird sicherheitshalber ein Blanker in die Ram:-Disk kopiert, wo
er auch erreichbar ist, wenn die Disk nicht da ist. Das macht Madhouse
nur bei eingeschaltetem Buffering. Ist die Disk aber doch da, kann ein
Blanker von dort nachgeladen werden, falls der Blanker im Speicher schon
benutzt wurde. Wenn die Disk aber nicht da ist, geblankt wurde, der User
abbricht, evtl. ein Pa
wort eingegeben wird, dann ggf. die Fehlermel-
dungen der Blanker in der Errorlist vom User best
tigt wurden, die Disk
immer noch nicht da ist, im Advanced-Options-Fenster "Nach Disk fragen /
Ask for Disk" gew
hlt wurde UND wenn der Speicher dazu reicht, wird noch
ein kleines Fenster auf der Workbench oder dem aktuellen PublicScreen
ffnet, welches auf diesen Zustand aufmerksam macht...
Zus
tzlich wird die amos.library auf die RAM:-Disk kopiert, damit die
AMOS-Blanker eine haben, wenn sie sie brauchen.
Wenn ein Blanker es erlaubt, einen Dateinamen einzustellen (ist momen-
tan noch nicht der Fall) dann @{B}m
ssen@{UB} Disketten-User diese Datei
in das Blankerunterverzeichnis kopieren, weil sie nur dort ggf. in die
Ram:-Disk gerettet wird. Im Stringgadget dieses BlankerPrefs-Fensters mu
dann nur der Dateiname eingetragen werden, ohne Pfad. Bei einer Eingabe
von FileXY sucht der Blanker also nach RAM:Madhouse_Storage/FileXY oder
Work:Madhouse/Blankers/NiceBlanker/FileXY, je nachdem, von wo er gestartet
wurde.
Aber das ist - wie gesagt - momentan noch unwichtig, da im Moment keine
Blanker existieren, die nach Dateinamen fragen.
@endnode
@node reference "Der Referenz-Teil"
Dieser Teil der Madhouse-Anleitung dient dem Nachschlagen der Gadgets
einzelner Fenster.
@{B}Ohne MUI:@{UB}
@{" Das Hauptfenster ",link ref_mainwin}
@{" Das BlankerPrefs-Fenster ",link ref_editPrefs}
@{" Das Advanced-Options-Fenster ",link adv_op}
@{" Die Error-List ",link errors}
@{" Das AskForDisk-Fenster ",link ref_littlewin}
@{B}Mit MUI:@{UB}
@{" Das Hauptfenster ",link ref_muimainwin}
@{" Das BlankerPrefs-Fenster ",link ref_editPrefs}
@{" Die Error-List ",link errors}
@{" Das AskForDisk-Fenster ",link ref_littlewin}
@{B}Tooltypes@{UB}
@{" CONFIGED ",link tt_configed}
@{" QUIETQUIT ",link tt_quietquit}
@endnode
@node tt_configed "Referenz: Tooltypes - CONFIGED"
CONFIGED
Der komplette Pfad des MadhouseConfigEd mu
direkt hinter dem "=" ange-
geben werden. Beispiel:
CONFIGED=Work:Madhouse/MadhouseConfigEd
Neben dem "=" d
rfen keine Leerzeichen stehen.
@endnode
@node tt_quietquit "Referenz: Tooltypes - QUIETQUIT"
QUIETQUIT
Wenn dieser Tooltype eingeschaltet ist, nervt Euch Madhouse nicht mit einem
Sicherungsrequester, wenn Ihr es durch erneuten Start beenden wolltet.
Wer den Requester haben will, mu
diesen Tooltype entfernen oder in
Klammern setzen.
@endnode
@node ref_mainwin "Referenz: Das Hauptfenster"
@{B}I. Wie man dieses Fenster
ffnet.@{UB}
Um dieses Fenster zu
ffnen, mu
man zuerst auf die Workbench klicken und
dann deren Tools- (Hilfsmittel-) Men
hlen. Darin befindet sich der Ein-
trag "Madhouse". Nach dessen Answahl
ffnet sich dann das Fenster.
@{B}II. Die Gadgets@{UB}
Witzigerweise wird hier jedes Gadget durch ein Gadget repr
sentiert.
Bei Anklick Infos.
Edit @{" Prefs... ",link main_edit}
@{" Listengadget ",link main_list}
Pfad/Path @{"Work:Tools/Ma",link main_path}
@{" Weitere Optionen/Advanced Options ",link main_advOpt}
Zeit/Time @{" | ",link main_time}
@{" ",link main_changeBl} Blanker wechseln/ Exchange Blankers
@{" Speichern/Save ",link main_save}
@{" Benutzen/Use ",link main_use}
@{" Entfernen/Remove ",link main_remove}
@{" Info ",link main_info}
@{B}III. Wie man die Einstellungen speichert.@{UB}
Auf "Sichern/Save" klicken.
@{B}IV. Wie man das Fenster schlie
t.@{UB}
Dazu dienen die Gadgets "Speichern/Save" und "Benutzen/Use". Achtung:
solange diese Fenster, das Advanced-Options-Fenster oder die Error-List
offen ist, wird Madhouse nach Ablauf der Zeit keinen Blanker starten.
@endnode
## The Gadgets
@node main_edit "Referenz - Hauptfenster: Edit"
Dieses Gadget beeinflu
t nur die Liste. Man kann hier zwischen der
Funktion der Liste umschalten. Es gibt zwei M
glichkeiten: "Selection/Aus-
wahl" schaltet die Liste in den Blanker-Auswahl-Modus. Jetzt kann man w
len, welche Blanker gezeigt werden sollen, wenn die Zeit nach einer
Schaffensphase um ist.
Ist "Einstellung/Prefs..." aktiv, bewirkt ein Klick in die Blanker-Liste
ffnen das BlankerPrefs-Fensters f
r diesen Blanker.
Ist das Gadget schraffiert und damit unbrauchbar gemacht, dann ist ein
falscher Pfad eingestellt.
Weitere Infos in @{"Der Workshop", link workshop}, Punkt 5.
@endnode
@node main_list "Referenz - Hauptfenster: Das Listengadget"
Die Liste ist mit dem Edit-Gadget verbunden. Wenn im Edit-Gadget "Einstel-
lung/Prefs..." eingestellt ist, zeigt die Liste die Namen aller Blanker.
Ein Klick auf einen Namen
ffnet das BlankerPrefs-Fenster, in dem die
Einstellungen f
r diesen Blanker gesetzt werden k
nnen.
Steht das Edit-Gadget jedoch auf "Auswahl/Selection", erscheinen vor den
Namen jeweils "
" oder " ". Ein "
" bedeutet, da
dieser Blanker ver-
wendet wird, ein " " markiert einen ausgeschalteten Blanker. Durch Klick
auf die Namen wechseln die Blanker zwischen den verschiedenen Betriebszu-
nden. Es mu
mindestens ein Blanker eingeschaltet bleiben.
Nur aus eingeschalteten Blankern wird dann im Lotterie-Verfahren einer
zum Blanken ausgew
Ist die Liste schraffiert dargestellt (geht nur unter OS3.0) oder reagiert
sie nicht, oder ist sie leer, dann stimmt der Pfad nicht. Bei Path
korrigieren.
Es kann sein, da
etwas am Blankers-Verzeichnis ge
ndert wurde und Mad-
house noch den alten Verzeichnisinhalt anzeigt. In diesem Fall braucht
man nur den Cursor in das Path-Gadget setzen (anklicken) und <Return> zu
cken. Wenn zus
tzlich abgespeichert wird, sind die Einstellungen auch
beim n
chsten Programmstart wieder vorhanden.
Weitere Infos in @{"Der Workshop", link workshop}, Punkt 5.
@endnode
@node main_path "Referenz - Hauptfenster: Pfad/Path"
Wenn das "Benutzen/Use"-gadget und einige andere unzug
nglich sind, wurde
ein falscher Pfad eingestellt. In diesem Gadget mu
der Pfad eingetragen
werden, in dem Madhouse seine Blanker sucht. Normalerweise endet der Pfad
mit /blankers, sofern der Name dieses Verzeichnisses nicht ge
ndert wurde.
Madhouse erkennt den Pfad
brigends nur als richtig, wenn sich noch die
Datei "the_right_drawer" darin befindet.
Der Pfad mu
absolut sein, d.h. den Namen der Diskette enthalten.
@endnode
@node main_advOpt "Referenz - Hauptfenster: Weitere Optionen/Advanced Options"
Madhouse hat mehr Optionen als in ein Hauptfenster passen... Deshalb gibt
es noch die Weiteren Optionen/Advanced Options, was nichts mit Chipsets zu
tun hat. Nach einem Klick auf den Button
ffnet sich ein Fenster mit satten
9 Gadgets zum Einstellen bestimmter Dinge, die Madhouse zu etwas Besonderem
machen. Die erkl
re ich aber nicht hier, sondern in @{"Die Advanced Options", link adv_op}.
@endnode
@node main_time "Referenz - Hauptfenster: Zeit/Time"
Nachdem die letzte Eingabe schon eine bestimmte Zeit her ist, wird der
erste Blanker gestartet. Diese Zeit kann mit dem "Zeit/Time"-Slider einge-
stellt werden. Die Zeit wird in Sekunden gemessen.
@endnode
@node main_changeBl "Referenz - Hauptfenster: Blanker wechseln/Exchange Blankers"
Mit diesem Gadget wird bestimmt, ob Madhouse die Blanker mitten im Blanken
auswechseln soll. So l
t sich im BlankerPrefs-Fenster mit dem "Dauer/
Duration"-Slider f
r jeden Blanker bestimmen, wie lange er laufen soll. Der
Slider wird freigegeben, wenn "Blanker wechseln/Exchange Blanker" aktiviert
Da das Wechseln des Blankers aber nur Sinn macht, wenn auch zwei oder mehr
Blanker in der Liste aktiviert sind, ist dieses Gadget auch nur dann ver-
gbar.
@endnode
@node main_save "Referenz - Hauptfenster: Speichern/Save"
Schlie
t das Fenster und sichert die Optionen. Diese Dinge werden dann
nach "ENVARC:/ENV:Madhouse.prefs" gespeichert:
- Die Optionen des Hauptfensters bzw. der System-Seite.
- Die Optionen des Advanced-Options-Fensters bzw. der Advanced/Optionen-
Seite.
- Die aktuelle Position des Waiting-For-Disk-Fensters; siehe
@{"Advanced-Options-Beschreibung", link adv_op}.
- Die Duration-Einstellung f
r jeden Blanker.
- Die Namen und ein/aus-Einstellungen der Blanker.
@endnode
@node main_use "Referenz - Hauptfenster: Benutzen/Use"
Dieses Gadget schlie
t das Hauptfenster und l
t Madhouse 'am Leben'.
Die Einstellungen werden
bernommen, aber nicht abgespeichert.
@endnode
@node main_remove "Referenz - Hauptfenster: Entfernen/Remove"
Beendet Madhouse.
@endnode
@node main_info "Referenz - Hauptfenster: Info"
Ein kleines Fenster
ffnet sich und zeigt einige Informationen
ber Mad-
house und die Autoren.
@endnode
@node ref_littlewin "Referenz: Das AskForDisk-Fenster (bei Nach Disk fragen)"
Das AskForDisk-Fenster (also das Fenster mit der kleinen Diskette) zeigt
an, da
der gepufferte Blanker bereits benutzt wurde und da
Madhouse
darauf lauert, die Blankers-Diskette in die Finger zu bekommen.
Ein Klick auf das Schlie
-Gadget dieses kleinen Fensters bewirkt nicht
nur das Schlie
en des Fensters, sondern stellt auch alle Schn
ffel-
versuche nach der Diskette ein.
@endnode
@node ref_editPrefs "Reference: The BlankerPrefs-window"
@{B}I. Wie dieses Fenster ge
ffnet wird:@{UB}
Dieses Fenster l
t sich ganz einfach
ffnen: Einfach das Hauptfenster
ffnen, dann das Edit-gadget auf "Prefs..." stellen und einen Blanker
anklicken! MUI-User m
ssen auf die Blankers-Seite wechseln und dann
einen Blanker anklicken.
@{B}II. Die Gadgets@{UB}
Genialerweise
ndern sich die Gadgets, je nachdem welcher Blanker ange-
klickt wurde. Einige sind jedoch immer gleich:
@{I}II.1 Das Okay-Gadget@{UI}
Speichert die Einstellungen unter "blankers/blankername/prefs".
@{B}Achtung:@{UB} Der Wert des Duration-Sliders wird hiermit nicht gespeichert,
sondern nur mit dem Save-Button des Hauptfenster!
@{I}II.2 Das Testen/Test-Gadget@{UI}
Dieses Gadget starte den Blanker mit den aktuellen Einstellungen.
@{I}II.3 Das Abbruch/Cancel-Gadget@{UI}
t das BlankerPrefs-Fenster ohne die Einstellungen zu
bernehmen.
@{I}II.4 Der Dauer/Duration-Slider (MUI: auf der Blankers-Seite vorhanden)@{UI}
Mit diesem Gadget wird eingestellt, wie lange Madhouse diesen Blanker
zeigt. Da die Blanker aber nur mit aktiviertem "Blanker wechseln/Exchange
Blankers" mittendrin abbrechen und wechseln, macht dieser Slider nur mit
"Blanker wechseln/Change Blanker" Sinn. Andernfalls ist er nicht bedienbar
(schraffiert).
@endnode
@node ref_muimainwin "Referenz: Das MUI-Hauptfenster"
@{B}Die Gadgets um unteren Fensterrand:@{UB}
@{" Speichern/Save ",link main_save}
@{" Benutzen/Use ",link main_use}
@{" Entfernen/Remove ",link main_remove}
@{B}System-Seite@{UB}
@{" Listengadget ",link ref_muilist}
@{" Pfad/Path ",link main_path}
@{" Zeit/Time ",link main_time}
@{"Blanker wechseln/Exchange Blankers",link main_changeBL}
@{B}Advanced/Optionen-Seite@{UB}
Siehe @{" Advanced Options ", link adv_op}
@{B}Blankers-Seite@{UB}
@{" Listengadget ",link ref_muibllist}
@{" Dauer/Duration ",link ref_muiduration}
@{" Autor/Author ",link ref_muiauthor}
@{" CPU-Belastung/CPU load ",link ref_muicpuload}
@{" Version ",link ref_muiversion}
@{" Das Sound-Men
als PopUp ",link ref_muisound}
@{B}Info-Seite@{UB}
@{" Textgadget ",link ref_muiinfo}
@endnode
@node ref_muilist "Referenz - Hauptfenster/System: Listengadget"
Die Liste links erm
glich die An- und Abwahl der einzelnen Blanker. Nur die
Blanker, die hier ausgew
hlt werden, werden sp
ter von der Zufallsfunktion
herangezogen. Die Auswahl mit der Liste kann umst
ndlich sein, wenn MUI
unpraktisch konfiguriert wurde.
Im MUI-Einstellungsfenster sollte auf der Listen-Seite das Gadget Auswahl
auf "immer" stehen. Zus
tzlich wird eine MUI-Multiselect-Liste
bersicht-
licher, wenn man auf der Bilder-Seite folgende Zuordnungen vornimmt:
BG Listview -> Stift / System / Hintergrund oder Fremd / irgendein Muster
BG Listview Cursor -> Muster / Scheinstift
BG Listview Selected -> Stift / System / F
llstift
BG Listview Selected+Cursor -> Muster / Schatten/F
ll-Raster
Wird die Liste schraffiert dargestellt, dann ist die Pfad/Path-Einstellung
falsch.
@endnode
@node ref_muibllist "Referenz - Hauptfenster/Blanker: Listengadget"
Die Blanker-Liste auf der Blankers-Seite ist f
r zwei Aufgaben zu ge-
brauchen: zwischen den Funktionen wird mit der Art des Mausklicks ent-
schieden.
- Einfachklick:
Die Informationen zum angeklickenten Blanker werden in den beiden Text-
boxen angezeigt, die sich rechts von der Liste befinden.
- Doppelklick:
Das BlankerPrefs-Fenster wird ge
ffnet. Finden sich in der gadget-Datei
des angeklickten Blankers keine Informationen zum Aufbau eines MUI-
Fensters, wird eben ein Normales aufgemacht.
@endnode
@node ref_muiduration "Referenz - Hauptfenster/Blanker: Dauer/Duration"
Mit diesem Gadget wird eingestellt, wie lange Madhouse den aktiven Blanker
zeigt. Da die Blanker aber nur mit aktiviertem "Blanker wechseln/Exchange
Blanker" mittendrin abbrechen und wechseln, macht dieser Slider nur mit
"Blanker wechseln/Exchange Blanker" Sinn. Andernfalls ist er nicht bedien-
bar (schraffiert).
@endnode
@node ref_muiauthor "Referenz - Hauptfenster/Blanker: Autor/Author"
In diesem Textfeld wird der Name des Autors angezeigt, der den gerade
angew
hlten Blanker programmiert hat.
@endnode
@node ref_muicpuload "Referenz - Hauptfenster/Blanker: CPU-Belastung/CPU load"
Dort ist die St
rke ersichtlich, mit der der Blanker das System belastet.
Danach entscheidet Madhouse - falls das Gadget "CPU aktiv/CPU active" auf
der Advanced/Optionen-Seite auf "nur einfache Blanker/only simple ones"
steht und ein Programm arbeitet - welcher Blanker verwendet werden kann.
Siehe auch @{"Advanced Options", link adv_op}. Die "Rechenintensivit
t" des
Blankers wird im Feld "CPU-Belastung/CPU load" angezeigt. "niedrig/low"
bedeutet eine niedrige Belastung, "mittel bis hoch/medium to high" eine
mittlere bis starke Belastung.
@endnode
@node ref_muiversion "Refernz - Hauptfenster/Blanker: Version"
In diesem Textfeld wird die Versionsnummer des vorliegenden Blankers
angezeigt.
@endnode
@node ref_muisound "Referenz - Hauptfenster/Blanker: Sound"
Mit diesem Sound-Men
kann man jedem Blanker einen Sound zuordnen, au
erdem
glicht es dieses PopUp, sich die Musik-Module anzuh
@{FG Highlight}Dazu wird entweder die medplayer.library oder der DeliTracker benutzt, je
nachdem, was auf der Advanced/Optionen-Seite eingestellt ist. Falls der
DeliTracker benutzt wird, mu
der DeliTracker laufen; sonst mu
medplayer.library verf
gbar sein und dann darf das Modul auch nur ein
MED-Modul sein.@{FG Filltext}
chst mu
man in der Liste links einen Blanker ausw
hlen (1x klicken),
der "vertont" werden soll. Das Stringgadget neben "Sound" enth
lt nun das
r diesen Blanker eingestellte Modul - also im Moment noch nichts. Das
PopUp-Gadget (MUI wird heute mal voll ausgereizt *(:-) ) auf der rechten
Seite mu
auch noch bet
tigt werden, schon
ffnet sich ein liebevoll
designtes PopUp-Fenster. Dieses PopUp besteht aus mehreren Elementen:
@{FG Highlight}Hinzuf
gen... / Add...@{FG Filltext}
Dieser Button mu
chst bet
tigt werden, um ein Sound-Modul in die Li-
ste zu bekommen
@{FG Highlight}L
schen / Del@{FG Filltext}
Hiermit wird ein Modul komplett aus Madhouse gestrichen. Jeder Blanker,
bei dem dieses Modul eingestellt war, hat nun keine Sound-Einstellung
mehr, und das Modul wird aus der Liste entfernt.
@{FG Highlight}Tapedeck-Play-Pfeil@{FG Filltext}
Nun, es soll ja Leute geben, die sich die Bedienungsanleitungen von
Radiorekordern, Tapedecks, CD-Playern und Videorekordern durchlesen.
Die haben jetzt keine Chance, weil ich nicht erkl
ren werde, was
dieser Button macht. Notfalls schaut halt in die Anleitung vom Auto-
Radio, Euch ist ja eh' nicht zu helfen.
@{FG Highlight}Tapedeck-Stop-Quadrat@{FG Filltext}
Mit diesem Knopf wird das Musik-Modul wieder gestoppt. %
@{FG Highlight}Liste@{FG Filltext}
Ach ja, die Liste: die hat eigentlich gar keine Bedeutung. Die ist nur
da, weil die Leute sowas erwarten, wenn sie ein PopUp
ffnen. Anstatt
des Sound-Men
tte es n
mlich auch ein simpler File-Requester getan,
aber wenn man nun mal gerne programmiert...
Zugegeben, man k
nnte das Sound-Modul auch direkt in das Stringgadget ein-
tragen. (Der Hypermegasupergeheimtip.)
brigens wird die Liste selbst nie abgespeichert. Falls also ein Modul hin-
zugef
gt, aber nicht benutzt wird, befindet es sich beim n
chsten Start
des MadhouseConfigEd nicht mehr in der Liste. Die Liste wird vielmehr am
Programmstart des ConfigEd anhand der eingestellten Module erstellt.
Einen interessanten Tip von Aicke m
chte ich auch nicht verschweigen: wenn
Ihr nicht wollt, da
der DeliTracker nach jedem Blanken wieder eines sei-
ner eigenen Module nachl
dt (wenn er also ohne Madhouse ruhig sein soll),
dann schaltet doch einfach die Option "Play at Start" ab.
@{FG Highlight}Halt, nach dieser sehr sinnvollen Beschreibung des Sound-PopUps noch was
Wichtiges: Eigentlich kann man die Sound-Funktion nur mit einer Festplatte
benutzen (die sowieso jeder Anwender haben sollte), weil Madhouse immer
davon ausgeht, da
das Modul ohne Diskettenwechsel (und damit ohne "Please
insert Disk..."-Requester) ladbar ist.
Uneigentlich geht es aber auch ohne, dazu mu
man das betreffende Sound-
Modul jedes Blankers in sein Unterverzeichnis kopieren. In das Sound-Gadget
(nicht ins PopUp, das wird nicht gehen) mu
man dann
RAM:Madhouse_Storage/mod.Musikmodul
eintragen, vorausgesetzt "Puffern/Buffering" ist eingeschaltet und das
Modul hei
t "mod.Musikmodul". Diesen Trick sollte man aber nur mit dem
DeliTracker anwenden, weil Madhouse die medplayer.library erst kurz vor dem
Abspielen
ffnet, was auch ein "Please insert Disk..." hervorrufen kann.
Siehe auch @{"Puffern/Buffering-Option", link buffering}.@{FG Filltext}
@endnode
@node ref_muiinfo "Referenz - Hauptfenster: Info"
In diesem Gadget werden einige Informationen
ber uns angezeigt. Au
erdem
findet Ihr hier das Madhouse-Logo (was Ihr bestimmt gesucht habt!)
@endnode
@node programmers "F
r Programmierer: eigene Module schreiben!"
Da Madhouse ein offenes System ist, kann man leicht eigene Module hinzu-
gen. Eure erste Frage ist sicherlich
@{" Kann ich meine Programmiersprache benutzen? ", link p_language}
Danach k
nnt Ihr einen Blanker schreiben und ihn Compilieren.
@{" Wie soll ich den Blanker schreiben? ", link p_code}
Jetzt f
gt Ihr Euren Blanker in den Madhouse-Verzeichnisbaum ein.
@{" Mein eigenes Verzeichnis! ", link p_dir}
Dies ist alles was Ihr braucht, um einen einfachen Blanker zu schreiben.
Aber ein richtiger Blanker hat schlie
lich auch Einstellungen, und die
ndert der User ja in Eurem zuk
nftigen BlankerPrefs-Fenster. Madhouse
erstellt es nach Euren W
nschen - oder besser gesagt, nach Eurer Datei.
Sie hei
t "gadget" und mu
sich im Verzeichnis des neuen Blankers befinden.
Und die wird jetzt erstellt.
@{" Die gadget-Datei. ", link p_gadget}
Und fertig! Wer hiermit Probleme hat, der sollte uns unbedingt schreiben.
Schlie
lich hat jeder Programmierer einmal angefangen und ich hatte keine
Versuchsperson, die nur anhand dieser Anleitung einen Blanker schreiben
sollte. Gerade weil f
r einen modularen Screenblanker die verf
gbaren Mo-
dule das Wichtigste sind, werden wir hier jede uns m
gliche Unterst
tzung
liefern. Nat
rlich kennen wir nicht jede Programmiersprache, aber das ist
oft auch nicht n
@{FG Highlight}Noch ein paar Worte an Leute, die tats
chlich einen Blanker schreiben und
ffentlichen wollen:
1. Wir haben bestimmte Dinge bewu
t nicht gemacht (?). So haben wir bewu
keinen Lines-Blanker geschrieben, weil der nicht gut aussieht und nicht
originell genug ist. Nat
rlich k
nnt Ihr ver
ffentlich, was Ihr wollt,
aber es w
re schon, wenn das Niveau von Madhouse erhalten bliebe. Die
Idee sollte also irgendwie ausgefallen sein.
2. Vielleicht denkt Ihr, es ist praktisch, Madhouse zusammen mit Eurem
Blanker zu ver
ffentlichen. Tut das bitte nicht, denn Madhouse darf
nur @{B}unver
ndert@{UB} weitergegeben werden. Wenn Ihr Euren Blanker
zwischen unseren sehen wollt, k
nnt ihr ihn uns schicken. Dann ist er
in der n
chsten Version dabei. In diesem Fall mu
er sich dann aber
unserer Qualtit
tskontrolle unterziehen (das h
rt sich jetzt arrogant
an, aber irgendwie mu
man sich ja absichern wenn doch einer mit Lines
ankommt). Bitte seid nicht b
se, wenn der Blanker mit drei Seiten
Verbesserungsvorschl
gen zur
ckkommt.@{FG Filltext}
@endnode
@node p_language "Kann ich meine Programmiersprache benutzen?"
Ja.
Wenn Ihr jetzt denkt, da
Ihr mit BASIC-m
igen Dialekten keine Chance
habt, dann liegt Ihr falsch. Immerhin wurden viele Blanker in AMOS ge-
schrieben, und das will schon was hei
en (ich will hier nicht das Ger
verbreiten, AMOS w
re nur zu sich selbst kompatibel. Nachher folgt dann
in der n
chsten Version dieser Anleitung eine Gegendarstellung, die
ich dann noch nicht einmal unterschlagen darf... oder so).
OK, wer also meint AMOS benutzen zu m
ssen, der soll das eben tun.
Um es auf dem Punkt zu bringen, mir fallen nur zwei "Sprachen" ein, mit
denen Ihr kein Gl
ck haben werdet. ARexx und AmigaDOS. "Waaaas, letzteres
ist eine Programmiersprache?" Streng genommen schon. Noch nie was von
Batch-Dateien geh
rt? Gut so.
ARexx geht auch nicht, weil man da keine Screens
ffnen kann. "Und das
t Ihr mir jetzt einfach glauben", w
rden die Physik-Lehrer sagen.
ARexx w
rde es theoretisch schaffen, wenn jemand vorher eine ARexx-
Extension-Lib mit neuen Befehlen f
r Screens und Zeichnen und so in
Assembler oder C schreiben w
rde. Und da h
rt dann der Sinn irgendwie auf,
oder? Tats
chlich existiert eine solche Library, die m
t Ihr jetzt aber
schon selbst suchen, und au
erdem br
uchtet Ihr dann noch den 250,-DM
teuren ARexx-Compiler, und daf
r bekommt man ja schon eine richtige Pro-
grammiersprache.
Tja, l
ngst habt Ihr es gemerkt. Ich bem
he mich immer, einleuchtend,
klar verst
ndlich und f
r jeden begreiflich zu schreiben. Kurz fassen
kann ich mich aber nicht.
Um also wieder auf den Punkt zu kommen: hiermit definiere ich eine
Madhouse-Blanker-m
gliche Sprache als alle Amiga-Sprachen abz
glich
der Sprachen f
r die es keinen Compiler gibt oder die keine M
glichkeit
bereitstellen, Screens oder Fenster zu
ffnen.
r AMOS und GFA-BASIC (und Amiga-BASIC...) gibt es den Compiler extra
zu kaufen. F
r ARexx auch, aber diesen Punkt h
tten wir ja nun abgehakt.
BlitzBasic, C, Pascal, Assembler, Oberon, Modula, Amiga-E, und alles
was mir sonst einfallen k
nnte sind sog. Compiler-Sprachen und werden
deshalb GARANTIERT mit Compilern ausgeliefert, da der Compiler sozusagen
die Sprache ist, wie sich ein Einsteiger ausdr
cken w
Alles klar? AmigaDOS (und ARexx?) sind aus dem Rennen, dem Rest w
nsche
ich viel Spa
@endnode
@node p_code "Wie ich meinen Blanker schreibe."
Wie Ihr Euren Blanker schreibt m
t nat
rlich Ihr entscheiden, aber ich
kann Euch sagen, wie er an die Daten von Madhouse herankommt und wie er
Madhouse Infos
bermitteln mu
Um die Kommunikation zwischen Blanker und Madhouse "programmiererfreund-
lich" zu gestalten (schlie
lich wollen wir hier niemanden zum Umsteigen
auf C zwingen...), haben wir uns entschlossen, alles mit Dateien abzu-
wickeln. Das hei
t, da
Madhouse eine bestimmte Datei, die immer denselben
Namen und Pfad hat, mit Informationen f
r den Blanker f
llt. Dann ruft es
den Blanker auf und macht erst weiter, wenn sich der Blanker beendet hat.
Der Blanker liest die Datei und zieht daraus seine Schl
sse - die Datei
namens "RAM:Madhouse_Storage/prefs" enth
lt die Einstellungen des Blankers
sowie die Duration-Zeit in Minuten (entspricht dem Duration-Slider im
BlankPrefs-Fenster) und einen neuen Pfad, der ihm sagt, wo sich sein
Hauptverzeichnis befindet. Diesen Pfad braucht man in den seltensten
llen, n
mlich genau dann, wenn man eine Datei aus dem Verzeichnis nach-
dt. Alle numerischen Angaben sind im Kartext geschrieben, z.B. "23" statt
". Die Frage "Wieviele Einstellungen hat denn mein Blanker?" solltet Ihr
selbst beantworten k
nnen... Da ein Programmlisting solche Sachverhalte
am besten verdeutlichen kann, gibt es drei Beispielprogramme. Das Erste ist
in dieser Datei enthalten und folgt gleich. Es ist sozusagen allgemein
gehalten. Au
erdem tut der Blanker hier nicht etwas bestimmtes und auch
auf die Parameter wollte ich mich nicht festlegen. Die beiden anderen
Programme befinden sich im developers-Verzeichnis und sind in C und AMOS
geschrieben. Sie enthalten richtige, handfeste Beispiele. Im Unterverzeich-
nis mit dem AMOS-Beispielblanker befindet sich noch eine Configurations-
Datei f
r die AMOSPro-Compilershell. Diese k
nnt Ihr einfach laden,
schon sind die Einstellungen korrekt.
brigens sollte man auf die abar-
tigen "Amos lock/unlock"-Kommandos achtgeben.
Datei "RAM:Madhouse_Storage/prefs" zum Lesen
ffnen.
Ersten eigenen Parameter lesen.
Zweiten eigenen Parameter lesen.
n-ten eigenen Parameter lesen.
Blank-Dauer in Minuten lesen.
Pfad auf die eigenen Dateien lesen.
Pfad ist z.B. "RAM:Madhouse_Storage" oder "Work:Madhouse/Blankers/MeinBl".
// Wenn die Zeit in Ticks ermittelt wird (DateStamp, der Timer)
Blankdauer = Blankdauer * 300
// Wenn die Zeit in Sekunden ermittelt wird (mit Include <time.h>)
Blankdauer = Blankdauer * 60
Screen
ffnen.
Wenn Fehler, dann
Datei "RAM:Madhouse_Storage/errors" zum ANH
NGEN (!)
ffnen.
Den Fehler in eine Zeichenkette kopieren,
an diese Zeichenkette das ASCII-Zeichen nummer 13 (0x0D) anh
ngen,
Fehler in Form EINER kurzen Zeichenkette schreiben.
Datei schlie
Programm beenden.
Aktuelle Systemzeit (Ticks) in eine Variable legen.
r immer
Blanken
Blanken
Blanken
(was der Blanker halt so in einer Hauptschleife macht...)
Wenn Maustaste gedr
ckt oder Tasteneingabe auf der Tastatur dann
Datei "RAM:Madhouse_Storage/Blankstop" zum Schreiben
ffnen.
Datei schlie
Screen schlie
Programm beenden.
)
Wenn Blanker-Dauer ungleich 0 dann
Zeit messen.
Wenn (aktuelle Zeit - Startzeit) > Blank-Dauer dann
Screen schlie
Programm beenden.
)
Ein paar Erl
uterungen sind sicher n
tig. So bedeutet die ) ein ENDIF-
iges Sprachkonstrukt.
Die Umrechnung der Blankdauer (*300 oder *60) mu
erfolgen, da Madhouse
die Zeit in Minuten
bergibt. Da man aber die Zeit in Sekunden oder Ticks
stoppt und die Startzeit in die Variable legt, mu
man die Madhouse-
Blankdauer mit 60 (Stoppeinheit Sekunden) oder mit 300 (Stoppeinheit Ticks)
multiplizieren. Dies wird auch in den beiden Beispielprogrammen veran-
schaulicht: das C-Demo benutzt die Funktion time() und die Struktur time_t
aus <time.h> und arbeitet in Sekunden. Das AMOS-Demo liest den Timer aus,
welcher die Zeit nach dem Einschalten in Ticks beinhaltet.
In die Errors-Datei darf deshalb nur eine Zeile ANGEHANGEN werden, weil
Madhouse die Datei erst auswertet, nachdem evtl. mehrere Blanker liefen.
So wird ein
berschreiben der Datei verhindert.
erdem ist noch wichtig, da
jeder Blanker nur EINMAL EINE ZEILE in die
"errors"-Datei schreiben darf, die dann von Madhouse umbrochen wird. Und
noch viel wichtiger ist, da
diese eine Zeile maximal 500 Zeichen lang
sein darf.
Die "prefs"-Datei sieht im
brigen z.B. so aus:
$Ein toller Text!
RAM:Madhouse_Storage
Dann hatte der Blanker selbst vier Einstellungen, die man im Prefs-Fenster
hlen kann. Sie werden hier in der Reihenfolge
bergeben, in der auch
die Gadgets in der "gadget"-Datei definiert sind, doch dazu sp
Hinter die Blanker-Einstellungen h
ngt Madhouse die Zeit in Minuten, die
der Blanker maximal blanken kann. Ist sie null, l
uft er tats
chlich bis
der Benutzer ihn abbricht. Als "Abbrechen" gilt
brigens nur eine Maus-
oder Keyboard-Taste. Strings werden Madhouse-Technisch mit einem $ ange-
hrt. Die Blanker-Einstellungen k
nnen alles m
gliche sein, z.B.
- der Wert eines Cycle-Gadgets
- der Wert eines Sliders
- der Zustand eines H
kchen-Gadgets (0 oder nicht 0 [0 hei
t "aus".])
- u.v.m.
Wie der Blanker das auswertet, bleibt ihm selbst
berlassen.
Ein sehr einfacher Blanker hat selbst gar keine Einstellungen und kein
Prefs-Fenster. Er liest dann z.B. nur
Work:Madhouse/Blankers/MeinBlanker
und reagiert darauf. Die "gadget"-Datei kann sich solch ein Blanker
schenken, daf
der Programmierer so eines Blankers aber eine prefs-
Datei selbst erzeugen, mit 0 Bytes L
nge. (So eine "leere" Datei befindet
sich auch im developer-Verzeichnis, unter dem Namen "emptyprefs".)
Das Executable, also die Datei, die hinten beim Compiler rauskommt, darf
sich
brigens auf keinen Fall vom CLI abkoppeln. Dies mu
auch im AMOSPro-
Compiler in der Compiler-Shell eingestellt werden (Option: CLI-Program
to run in the Background... No - oder so
hnlich).
brigens ist es f
AMOS-Programmierer schon recht wichtig, die mitgelieferten Compiler-
Settings zu benutzen. Aicke und ich hatten damals eine Menge
rger, als
wir erstmals einen AMOS-Blanker in das System integrierten. Den solltet
Ihr Euch mit der mitgelieferten Config-Datei ersparen.
@endnode
@node p_dir "Mein eigenes Verzeichnis!"
Madhouse f
r jeden Blanker ein eigenes Verzeichnis erwartet, sollte
nun langsam klar sein. Deshalb solltet Ihr jetzt ein Verzeichnis mit dem
Namen des Blankers im Madhouse-Blanker-Verzeichnis-Pfad (Ihr wi
t, was
ich meine...) anlegen.
Ein Verzeichnis hat im
brigen nicht nur die Aufgabe, alles beisammen
zu halten, User ohne Festplatte k
nnen - falls Euer Blanker die Angabe
eines Dateinamens erlaubt - diese Datei in das Blankerverzeichnis ko-
pieren. Da bei eingeschaltetem Buffering immer das gesamte Verzeichnis
im RAM gehalten wird, wird dann diese Datei auch erreichbar sein.
Der User gibt dann nur den puren Dateinamen an. Der Blanker versucht erst,
den Pfad, den Madhouse in die letzte Zeile der Prefs-Datei schreibt + "/"
+ den Dateinamen zu
ffnen, wenn das fehlschlug, dann nur den Datei-
namen allein.
Bei eingeschaltetem Buffering geht die erste Variante: aus dem Dateinamen
"File" wird dann "RAM:Madhouse_Storage/File". Bei ausgeschaltetem Buffering
gt diese Variante fehl, denn der User mit Festplatte mu
ja seine
Datei nicht in das Unterverzeichnis des Blankers kopieren. Er gibt z.B. an:
"Work:Pictures/File" und es entsteht
"Ram:Madhouse_Storage/Work:Pictures/File", was sich nat
rlich nicht
ffnen
t. Daf
r funktioniert dann aber Variante 2 (nur der Dateiname):
"Work:Pictures/File" m
te sich jetzt
ffnen lassen.
Das Verzeichnis kann nat
rlich auch zus
tzliche Dateien beinhalten,
die der Blanker dann beim Start immer nachl
dt. Wichtig ist aber, da
diese Dateien nicht "errors" oder "stopblank" hei
rfen. Ebenfalls
rfen keine weiteren Unterverzeichnisse angelegt werden.
Also dann, macht ein Verzeichnis und legt das Kompilat Eures Blanker
hinein. Der Blanker mu
den Namen "blanker" tragen (ach so).
erdem solltet Ihr noch eine leere Prefs-Datei erzeugen, wenn ihr
den Blanker zuerst ohne gadget-File und ohne BlankerPrefs-Fenster von
Madhouse aus starten wollt. Diese Datei mu
dann "prefs" hei
en (ach ja)
und sich in Eurem Blankers-Verzeichnis befinden. Da es nicht so leicht
ist, eine Datei wirklich leer zu machen, k
nnt Ihr die leere prefs-Datei
aus dem developers-Verzeichnis benutzen.
Diese leere Datei k
nnt Ihr Euch sparen, wenn Ihr jetzt die folgenden
beiden Abs
tze nicht mitmacht und gleich an die gadgets-Datei geht. Danach
ruft Ihr einfach das BlankerPrefs-Fenster Eures Blankers auf, bewegt alle
Slider und klickt auf Save. Schon habt ihr eine fertige Prefs-Datei.
Jetzt mu
Madhouse gestartet werden. Klickt einmal ins "Path"-String-
gadget und dr
ckt <Return>, damit Madhouse das Verzeichnis neu einliest.
Das BlankerPrefs-Fenster kann nat
rlich noch nicht ge
ffnet werden, da
die Definitionsdatei daf
r nach fehlt. Wenn der Blanker schon so pro-
grammiert wurde, da
er eigene Einstellungen liest, m
t Ihr halt selbst
eine prefs-Datei schreiben, die NUR DIE EINSTELLUNGEN DES BLANKERS ent-
lt. Wie so etwas auszusehen hat, wi
t Ihr ja. Aber soetwas w
rde ich
selbst nicht gleich ausprobieren, besser erst den Blanker anpassen, so
er keine eigenen Einstellungen l
Bei "Selection" k
nnt Ihr noch Euren Blanker allein ausw
hlen, auf
"Use" klicken und - warten.
@endnode
@node p_gadget "Die gadget-Datei"
Da ja mittlerweile auch den Lesern der Commodore-Dokumentation klar ist,
was Gadget hei
t (Ihr wi
t schon, die Dinger auf die Ihr dauernd klickt..),
rfte die Bedeutung der "gadget"-Datei, die eigentlich jeder Blanker in
seinem Verzeichnis hat, klar sein. Sie enth
lt u.a. die Beschreibung,
wie das BlankerPrefs-Fenster des jeweiligen Blankers aussieht.
Und damit der Anfang wieder einfach wird, schauen wir uns zun
chst eine
solche Datei an, die ich zwecks Dateif
llung mal hier eingef
gt habe.
(Anm.: Diese Datei ist nicht lokalisiert, d.h. ist nur einsprachig. Zur
Erzeugung mehrsprachiger BlankerPrefs-Fenster komme ich sp
ter.)
Madhouse v1.0, BlankerPrefs-Window
CHUNK:DIMENSIONS
Gadgets 3
Texts 5
Arrays 1
CHUNK:WINDOW
338,62
CHUNK:DURATION_POS
112,53,150,12
CHUNK:GADGETS
Cycle,112,4,150,12,Mode,TextLeft
1,Done
3,Bouncing Point,Wusel,Random
Slider,112,19,150,12,Wusel lenght,TextLeft
5,SlMin,1,SlMax,20,Done
Checkmark,112,34,26,12,Sound,TextLeft
1,Done
(.... Hier steht noch die MUI-Fensterbeschreibung, die ich weiter unten
re. Sie ist nicht zwingend notwendig.)
CHUNK:BEVELBOXES
0,0,330,49
0,49,330,20
CHUNK:BLANKERINFO
Aicke Schulz
Ha! Obwohl Ihr bisher nicht die leiseste Ahnung vom Aufbau der Datei habt,
kann jetzt jeder sofort sehen, von welchem Blanker die Datei stammt.
Es tauchen n
mlich bestimmte Schriftz
ge auf, die der erfahrene (ahem..)
Madhouse-User schon gesehen hat.
Na klar, von CrazyPixel stammt diese Datei. Und offensichtlich ist sie
auf eine bestimmte Art strukturiert. So ist des
fteren das Wort CHUNK
darin zu finden.
Auf f
nf Dinge ist zu achten:
- Der Text "Madhouse v1.0, BlankerPrefs-Window" MUSS sich in der ersten
Zeile befinden.
- Die Chunks k
nnen gemischt werden.
- Der erste Chunk mu
der "CHUNK:DIMENSIONS" sein. Hier ist auch leider
der etwas invariable Programmierstiel erkennbar, den ich f
r die Daten
dieses Fenster angewandt habe... (mit MUI ist das alles schon etwas
genialer programmiert worden, aber egal.)
- Es d
rfen keine Leerzeilen innerhalb des Chunks liegen. Auf Recht-,
Gro
- und Kleinschreibung wird geachtet. Ausnahmen nerven die Regel:
weil sonst die
bersicht echt futsch gegangen w
re, sind im CHUNK: -
GADGETS doch Leerzeilen m
glich, aber auch dort nicht
berall...!
- Es d
rfen Leerzeilen zwischen den Chunks stehen, ein Chunk
(CHUNK:GADGETS) erlaubt auch Leerzeilen zwischen den einzelnen Gadget-
Definitionen. (Also zwei Regeln und eine Ausnahme.==)
Als kleinen
berblick will ich noch die Funktionen der einzelnen Chunks er-
ren, bevor ich weiter unten genau auf die Details eingehe.
Der CHUNK:DIMENSIONS sagt Madhouse, wieviele Gadgets das BlankerPrefs-Fen-
ster haben wird, damit es rechtzeitig den Speicher f
r die Daten besorgen
kann. Die beiden anderen Angaben haben ebenfalls mit der Speicherverwaltung
zu tun.
Der CHUNK:WINDOW bestimmt die Ausma
e des BlankerPrefs-Fensters (Breite
und H
Der CHUNK:DURATION_POS erlaubt die Positionierung des Duration-Sliders, der
von Madhouse selbst erzeugt wird und der sich in allen BlankerPrefs-Fen-
stern befindet.
Im CHUNK:GADGETS wird jedes Gadget des BlankerPrefs-Fensters gesondert de-
finiert. Die Buttons Okay, Test und Cancel sowie der Duration-Slider wer-
den hier nicht erstellt. Anhand des CHUNK:GADGETS bastelt Madhouse die
Daten zusammen, die vom Betriebssystem zum
ffnen des Fensters ben
werden.
Der CHUNK:LOCALE mu
nicht vorhanden sein, erlaubt es jedoch, mehrsprachige
BlankerPrefs-Fenster zu erzeugen. Nur sinnvoll und m
glich, wenn der CHUNK:
GADGETS und evtl. der CHUNK:MUI-WINDOWLAYOUT entsprechend angepa
t werden.
Diese Anpassung wird ebenfalls hier erkl
Der CHUNK:BEVELBOXES ist (wie auch der CHUNK:TEXTS) optional, d.h. er mu
sich nicht in der gadget-Datei befinden. Der CHUNK:BEVELBOXES erm
glicht,
wenn vorhanden, die Erzeugung von plastischen Rahmen im BlankerPrefs-
Fenster. Damit lassen sich verschiedene Gadgets prima gruppieren; in den
Madhouse-Blankern wird dieser Chunk immer eingesetzt, um den Duration-
Slider von den Blanker-Gadgets zu trennen. Mit dem CHUNK:TEXTS lassen
sich beliebige Texte ins BlankerPrefs-Fenster einf
Der CHUNK:BLANKERINFO mu
dagegen wieder in jeder gadget-Datei enthal-
ten sein. Er wird haupts
chlich nur eingelesen, wenn Madhouse nach einer
Eingabe im Path-Gadget des Hauptfensters das gesamte Blankers-Verzeichnis
durchw
hlt und die dort vorhandenen Blanker in der Liste eintr
gt. Aus
dem CHUNK:BLANKERINFO kann Madhouse ersehen, ob der Blanker rechenin-
tensiv ist (siehe @{"Advanced Options",link adv_op}, Punkt 4 ), und mit wieviel Stack
er gestartet werden mu
Noch ein kleiner Tip: Wer nicht wei
, was Radio-Gadgets u.s.w. sind, der
kann sich auch den recht informativen Artikel in der Amiga-Plus 11/93,
Seite 95f durchlesen. Hier werden auch die Einsatzgebiete der Gadgets
utert. Wessen Fenster auch noch total (Commodore-) Standard aussehen
sollen, der kann sich noch (aber das ist f
r diesen Zweck echt
bertrieben) den "AMIGA User Interface Style Guide", Addison-Wesley, 206
Seiten, ca. 60 DM 'reinziehen. Dieses Buch ist aber eigentlich nur f
die Programmierer gedacht, die ein Programm mit Fenstern schreiben.
Madhouse ist auch "Style-Guide"-konform, obwohl ich nie ein Blick in den
Interface Style Guide warf. Mit der Zeit kapiert man einfach, da
man die
Gadgets nicht wild im Fenster herumstreuen sollte...
Und jetzt folgt die Erkl
rung der einzelnen Chunks. Mit "*" markierte
Chunks m
ssen nicht auftauchen, k
nnen aber. (Optional.)
@{" CHUNK:DIMENSIONS ", link p_dimensions }
@{" CHUNK:WINDOW ", link p_window }
@{" CHUNK:DURATION_POS ", link p_duration }
@{" CHUNK:GADGETS ", link p_gadgets }
@{" CHUNK:BLANKERINFO ", link p_blankerinfo }
@{" * CHUNK:BEVELBOXES ", link p_bevelboxes }
@{" * CHUNK:TEXTS ", link p_texts }
@{" * CHUNK:LOCALE ", link p_locale }
Bis jetzt habe ich Euch ganz diskret verschwiegen, wo denn nun die Blanker-
Prefs-Oberf
chen des @{B}MUI-@{UB}Programmteils herkommen. Auf meine Kosten kann
mlich auch jeder Blanker, der in AMOS oder sonstwas geschrieben wurde,
eine MUI-Oberf
che haben. Die wird - wie konnte es anders sein - auch
einen Chunk erzeugt.
Man sollte den Text, der da oben steht, bereits verstanden haben um hier
weiterzumachen. Ich baue jetzt n
mlich ein bischen auf dieses Wissen auf.
erdem sollten sich auch in jeder fremden gadget-Datei die Informationen
zum Aufbau eines normalen Fensters (ohne MUI) finden, sonst kann Euer
Blanker nur von Usern der MUI-Version genutzt werden. Umgekehrt k
aber die MUI-Angaben fehlen.
Doch MUI-Oberfl
chen werden nicht einfach so pixelweise in den Raum ge-
stellt, sondern bauen sich aus Beziehungen einfacher Gestaltungsm
glich-
keiten auf. Deshalb mu
ich jetzt auch etwas weiter ausholen, denn die
Beschreibung von MUI bleibt mir wohl nicht erspart. Vorher jedoch noch
@{" Der MUI-Madhouse-Schnelleinstieg f
r erfahrene MUI-Programmierer. ",link pm_exp}
Alle anderen Leute mit MUI-Ambitionen lesen besser
@{" MUI von Null auf Hundert f
r MUI-Greenhorns. ",link pm_start}
@{" Die MUI-Gruppentypen ",link pm_groups}
@{" Die MUI-Gadgets ",link pm_gadgets}
@{" Der CHUNK:MUI-PREFSORDER ",link pm_mpo}
@endnode
@node p_dimensions "CHUNK:DIMENSIONS"
Dieser Chunk mu
der erste Chunk sein. Er beinhaltet drei Zahlen:
CHUNK:DIMENSIONS
Gadgets x
Texts y
Arrays z
x = Die Anzahl der Gadgets in Eurem Fenster. Hier werden nur selbst-
definierte gez
hlt, die Duration- und Test-Ok-Cancel-Buttons nicht.
y = Die Anzahl der Texte. Sie ist Anzahl der Gadgets (f
r den Namen) +
die Anzahl der gesamten Auswahlm
glichkeiten von Cycle- und Radio-
gadgets.
Die "richtigen" Texte des Text-Chunks werden nicht mitgez
Also einfach die Menge der eigenen Gadgets und die Anzahl der Cycle-
Eintr
ge addieren, und man hat y.
y = Die Menge der Cycle- und Radio-Gadgets.
@endnode
@node p_window "CHUNK:WINDOW"
CHUNK:WINDOW
x = Die H
he des BlankerPrefs-Fensters in Pixeln.
y = Die Breite des BlankerPrefs-Fensters in Pixeln.
@endnode
@node p_duration "CHUNK:DURATION_POS"
CHUNK:DURATION_POS
x,y,w,h
Wie schon mehrmals angesprochen, geh
rt der Duration-Schieber nicht zu
den selbstdefinierbaren Gadgets. Madhouse erledigt hier die Arbeit.
Da aber ein frei in der Gegend positionierter Slider nicht gut aussieht,
gibt es trotzdem die M
glichkeit, den Platz und die Gr
e des Duration-
Sliders zu bestimmen:
x = Linke Ecke des Duration-Sliders.
y = Obere Ecke des Duration-Sliders.
w = Breite des Sliders.
h = H
he des Sliders.
@endnode
@node p_gadgets "CHUNK:GADGETS"
Dieser Chunk enth
lt 1 bis n-mal eine solche Angabe:
Typ,x,y,w,h,Name,Flags
Anzahl der Tags,Tag1,Data1,Tag2,Data2...
[Anzahl der Array-Elemente,Element1,Element2,...]
Vor jeder dieser Zeilenbl
cke d
rfen beliebig viele Leerzeilen (zur
sichtlichkeit) stehen, jedoch nicht IN einem solchen Block (vgl. auch an-
dere Gadget-Dateien).
Das sieht jetzt sehr schwierig aus, aber man kann ja schlie
lich bei
den anderen Blankern abgucken... Au
erdem werde ich noch Beispiele bringen.
Die erste Zeile ist immer
hnlich:
Typ = Typ des Gadgets. Hier wird zwischen Stringgadgets (f
r Zeichen-
ketten), Sliders (die Schieberegler), Cycles (die 'Bl
ttersym-
bole'), Integergadgets (f
r Ganzzahlen), Checkmarks (die H
kchen-
gadgets) und MX's (auch Radiobuttons genannt, hat nichts mit
Rundfunk zu tun) unterschieden.
Je nachdem, was f
r ein Gadget man erstellen m
chte, schreibt
man hier
String f
r Stringgadgets,
Checkmark f
r Checkmark-gadgets,
Slider f
r Sliders
Cycle f
r Cycles
Number f
r Integer-gadgets oder
Radio f
r Radio- bzw. MX-gadgets.
Die anderen Typen sind in Madhouse nicht m
glich oder nicht re-
levant.
x,y,w,h = Die Positionen und Dimensionen des Gadgets. x,y = linke, obere
Ecke, w = Breite, h = H
Name = Text, der z.B. neben dem Gadget stehen soll.
Flags = Hiermit wird definiert, wo der Text "Name" stehen soll:
TextLeft der Text steht links neben dem Gadget,
TextRight der Text steht rechts neben dem Gadget,
TextTop der Text steht
ber dem Gadget oder
TextBottom der Text steht unter dem Gadget.
Die zweite Zeile ist die Tag-Zeile. Denn manche Gadgets ben
tigen noch
weitere Informationen, und die werden mit Tags
bergeben. Ein Slider
z.B. wissen was sein Wertebereich ist.
Die Tag-Zeile beginnt immer mit der Anzahl der Tags, z.B. "1".
Viele Gadgets ben
tigen so etwas aber nicht, deshalb schreibt man da
1,Done
Jede Tag-Zeile mu
mit einem "Done" aufh
Bei einem @{B}Slider@{UB} hei
5,SlMin,minimum-Wert,SlMax,maximum-Wert,Done
r "minimum-Wert" und "maximum-Wert" mu
rlich etwas nach eigenen Vor-
stellungen eingesetzt werden.
Auch ein @{B}Stringgadget@{UB} kann Tags besitzen:
3,StMaxChars,maximale Anzahl Zeichen,Done
Hier wird f
r "maximale Anzahl Zeichen" ein Wert eingesetzt, der angibt,
wieviel Zeichen das Stringgadget maximal aufnehmen darf. Wird mehr als 500
angegeben, oder lautet die Zeile nur
1,Done
dann wird der Default-Wert von 500 Zeichen benutzt.
Das waren schon alle Gadgets, die Tags ben
tigen.
Die Schl
sselw
rter ("String", "Checkmark", "TextRight", "SlMin", "Done",
u.s.w.) k
nnen in Egalschreibung geschrieben werden (also Pascal-gro
oder
C-klein oder ARexx-gemischt oder irgendwie).
Die dritte Zeile ist die Array-Zeile. Cycle-Buttons und Radio-Gadgets
noch mitgeteilt werden, was als m
gliche Auswahl zur Verf
steht. Achtung: sind die Werte im CHUNK:DIMENSIONS richtig gesetzt?
(Man mu
die Radio- und Cycle-Gadgets durchz
hlen und das Ergebnis unter
"Arrays" im CHUNK:DIMENSIONS eintragen. Dies steht aber dort erkl
Als Beispiel dient jetzt ein Cycle, welches zwischen vier Farbpaletten
umschalten l
Cycle,140,20,200,12,Farbauswahl,TextLeft
1,Done
4,Farbset 1,Farbset 2,Farbset 3,Farbset 4
Die erste Ziffer ist wieder die Anzahl der Auswahlm
glichkeiten.
@endnode
@node p_duration "CHUNK:DURATION_POS"
@node p_locale "CHUNK:LOCALE"
CHUNK:LOCALE
sprache1,sprache2,...
Bei der Lokalisierung von Madhouse sto
ich auf das Problem der Blanker-
Prefs-Fenster, die ja nicht auch noch alle ihren eigenen catalog haben
sollten.
Deshalb m
ssen - falls dieser CHUNK in der Datei vorkommt - die Chunks
GADGETS und MUI-WINDOWLAYOUT in den Angaben f
r Gadgettexte jeweils
alle verschiedenen Sprachen beinhalten. Um das nicht zu kompliziert zu
ren, zeige ich Euch zwei Beispiele:
CHUNK:GADGETS
CYCLE,112,4,170,12,"Mode,Modus",TEXTLEFT
1,DONE
3,"Bouncing Point|Wusel|Random,Springender Punkt|Wusel|Zufall"
SLIDER,112,19,170,12,"Wusel lenght,Wusell
nge",TEXTLEFT
5,SLMIN,1,SLMAX,20,DONE
CHECKMARK,112,34,26,12,"Sound,Toneffekt",TEXTLEFT
1,DONE
CHUNK:MUI-WINDOWLAYOUT
ColumnGroup(2),
Label( "_Mode,_Modus" ),
Cycle( "m", "Bouncing Point|Wusel|Random,Springender Punkt|Wusel|Zufall" ),
Label( "Wusel _lenght,Wusel_l
nge" ),
Slider( "l", 1, 20 ),
Label("_Sound,To_neffekt"),
HGroup,
CheckMark( "s,n" ),
HVSpace,
End,
Diese beiden Chunks aus CrazyPixel/gadget zeigen wohl alle Problemf
die mir spontan einfallen. Da es in der Gadgetdatei keine Texte gibt,
die sich nicht irgendwie auf die Bildschirmausgabe beziehen, sind alle
Textangaben (erkennbar an den "-Zeichen) vom Locale-Chunk betroffen.
Leser, die bis jetzt noch keinen CHUNK:MUI-WINDOWLAYOUT vor Augen hatten,
brauchen sich den ja nicht anzusehen, erst nachdem sie die MUI-Kapitel
gelesen haben.
Wie man problemlos erkennen kann, hat jede Textangabe ein , in der Mitte.
Dieses ist auch echt wichtig, da die Kommas die Sprachen voneinander
trennen. Hier sind die linken Teile (also die 1. Sprache) englisch, und die
rechten Teile (2. Sprache) deutsch. Also sieht der passende CHUNK:LOCALE
so aus:
CHUNK:LOCALE
english,deutsch
Weitere Sprachen k
nnten folgen, dann m
ssen aber auch alle Texte dement-
sprechend mehr Kommas haben. Madhouse geht nun folgenderma
en vor:
- Wenn am Programmstart des MadhouseConfigEd bereits festgestellt wurde,
dies kein OS 2.1-oder-h
her-Amiga ist, wird ab sofort "english" als
die voreingestellte Sprache angesehen; sonst die Sprache, die man im
Locale-Editor der Workbench eingestellt hat (also z.B. "deutsch").
- Bevor nun ein BlankerPrefs-Fenster ge
ffnet wird, wird die zugeh
gadget-Datei nach dem CHUNK:LOCALE durchsucht (Ihr glaubt gar nicht, was
das arme Ding alles mitmachen mu
...). Ist der nicht da, werden die Texte
innerhalb der Anf
hrungszeichen einfach ins Fenster
bernommen, und
diese Aufstellung hier hat ein Ende.
Ist er aber da, wird nachgesehen, ob die Zeile mit den Sprachennamen die
eingestellte Sprache (also f
r OS 2.0 "english") beinhaltet, und wenn ja,
nach dem wievielten Komma. Wenn nicht, wird die Sprache verwendet, die
zuerst aufgef
hrt wird (SOLLTE "english" sein).
- Trifft nun Madhouse beim Aufbau der Gadgets auf Texte, also auf etwas das
mit " anf
ngt, so werden einfach dementsprechend viele Kommas
sprungen, je nachdem, an welcher Stelle die ausgew
hlte Sprache stand.
Das Ergebnis wird weitergeleitet.
Wie oben im GADGET-Chunk ersichtlich ist, hat bei Cyclegadgets das Komma
eine h
here Priorit
t als das Trennzeichen |. Es wird also nicht jeder
einzelne Cycleeintrag umgesetzt, sondern der gesamte Text. Au
erdem sind
r MUI-Programmierer - auch die Tastaturbelegungen als Texte anzusehen.
Diese sind also auch lokalisiert, f
r den Fall, da
ein deutsches Wort
keinen Buchstaben des englischen Wortes enth
lt. Dementsprechend k
die Buchstaben in den Gadgettexten anders unterstrichen werden, und die
Gadgettasten k
nnen unterschiedlich sein, wie bei "_Sound,To_neffekt".
Wenn sich jedoch die Gadgettexte oder Tasten nicht unterscheiden, mu
nicht extra "_Level,_Level" oder "l,l" geschrieben werden, "_Level" oder
"l" reicht aus. Wenn Madhouse n
mlich kein Komma findet, wird die Locale
einfach nicht beachtet.
Der LOCALE-Chunk selbst mu
die Sprachennamen in Kleinschrift enthalten,
und zwar in der Sprache auf die sie sich beziehen. Alles klar? N
Was ich meine, ist, da
man fran
ais anstatt von franz
sisch schreiben
Hoffentlich ist der Locale-Chunk nun nicht zu einem der schwersten ge-
worden. Es gibt da halt soviele Sonderf
lle, OS 2.0 oder dr
ber, ver-
wendet oder nicht, vorn oder hinten, ...
Aber das Beispiel hat doch alles klar gemacht, oder? Nat
rlich, Carsten!
Na prima, dann kann ich ja wieder beruhigt einschlafen.
@endnode
@node p_blankerinfo "CHUNK:BLANKERINFO"
Dieser Chunk wird nicht f
r das BlankerPrefs-Fenster ben
tigt, sondern
er wird von Madhouse w
hrend des Verzeichnisbaum-Lesens gelesen.
Er enth
lt allgemeine Infos zum Blanker. Einige Daten werden nur vom MUI-
Programmteil ausgewertet, aber bitte trotzdem immer alles ausf
llen!
@{B}EXTREM WICHTIG: Madhouse schaut sich die Daten in diesem Chunk NUR
beim Lesen des Verzeichnisses (Path-Gadget benutzen) an. Das hei
t, da
eine
nderung an diesen Werten nur dann eine Auswirkung auf Madhouse
und den Blanker hat, wenn das Blankers-Verzeichnis neu gelesen wird.
Bis dies nicht geschieht, arbeitet Madhouse mit den alten CPU-Usage und
Stack-Werten.
@{UB}
CHUNK:BLANKERINFO
Version
CPU-usage
Stack
Name = Der Name des Autors.
Version = Die Versionsnummer des Blankers. F
ngt ab 1 an und wird dann
ganzzahlig heraufgez
hlt. 1.4 ist also falsch; 3, 6, 8008743
gehen aber.
CPU-Usage = kann 1 oder 0 sein. Wenn "CPU active:" auf "only simple Blan-
gers" gestellt ist, mu
Madhouse wissen, ob der Blanker die CPU
stark (1) oder fast gar nicht (0) beansprucht. 1/3 Belastung
w
rde ich noch zu 1 z
hlen! Den ganzen CPU-Krams habe ich schon
in @{"Advanced Options",link adv_op} erkl
rt. Entscheidet
selbst, ob Ihr neben Eurem Blanker einen Raytracer laufen lassen
w
rdet... Die CPU-Belastung kann mit einem entsprechenden Tool
gemessen werden.
Stack = h
ngt von Eurer Programmierweise und dem Compiler ab. Zuerst
sollte man es mit 5000 probieren und den Blanker gr
ndlich
austesten. Bei Problemen, die sich in Form von Abst
ern sollten, einfach mehr probieren. Eventuell legt der
Compiler (in C kann man das mit static bestimmen) alle Daten
des Programms auf den Stack, dann kann man schnell die ben
tigte Menge Speicherplatz
berschlagen.
Wenn sich Rekursionen im Programm befinden, sollte der Stack
ebenfalls gro
gig bemessen sein. (Hi Einsteiger: wer nicht
wei
, was Rekursionen sind, der hat auch keine im Programm!)
@endnode
@node p_bevelboxes "CHUNK:BEVELBOXES"
Was ist plastisch, dreidimensional, sieht aus wie ein Button und ist
(fast) v
llig nutzlos?! - Bevelboxen!
Bevelboxes sind die Umrandungen, die mehrere Gadgets zu einer Gruppe zu-
sammenfassen. Im nicht-MUI-Fenster des Stars-Blankers kann man sie gut er-
kennen. (Kleiner Tip: wer sich die BlankerPrefs-Fenster ansehen will, die
von Madhouse erzeugt werden, wenn MUI nicht vorhanden ist, der kann
- entweder die betreffende gadget-Datei um einen MUI-WINDOWLAYOUT-Chunk
rmer machen oder
- den ConfigEd mittels Use oder Save beenden, alle anderen MUI-Anwen-
dungen beenden, mit "avail flush" in der Shell die muimaster.library
aus dem Speicher r
umen und diese Library umbenennen. Dann kann der
ConfigEd sie nicht mehr finden, wenn er aufgerufen wird, und
ffnet von
nun an auch die normalen BlankerPrefs-Fenster.)
CHUNK:BEVELBOXES
Menge
x,y,w,h
[x,y,w,h]
[x,y,w,h]
[...]
Menge = Die Anzahl der Bevelboxes.
x = X-Position der Box.
y = Y-Position der Box.
w = Breite der Box.
h = H
he der Box.
Hinter dem Chunk-Header folgt die Anzahl der Boxen. Dann dieselbe Anzahl
Zeilen, jede Zeile definiert eine Box.
@endnode
@node p_texts "CHUNK:TEXTS"
Der Text-Chunk erlaubt das Schreiben in die BlankerPrefs-Fenster. So
nnen Texte erzeugt werden, die nicht direkt zu einem Gadget geh
sondern frei in der Gegend positioniert werden k
nnen.
CHUNK:TEXTS
Menge
Farbe,x,y,Text
[Farbe,x,y,Text]
[Farbe,x,y,Text]
[...]
Menge = Die Anzahl der Texte.
Farbe = Die Farbe des Textes (am besten nur 1 - 3).
x = X-Position des Textes.
y = Y-Position des Textes.
Text = Der Text selbst. Bitte ohne Anf
hrungszeichen.
Ein solcher Text-Chunk ist ebenfalls im Stars-Blanker-"gadget"-file zu
finden. Der Aufbau des Chunks
hnelt dem der Bevelboxes, erst die Anzahl
der Texte und dann genausoviel Zeilen darunter, jede Zeile spezifiziert
einen Text.
@endnode
## -------------------------------------------------------------------
@node pm_exp "Madhouse-MUI f
r Leute, die sich schon auskennen."
In diesem Kapitel werden nur die Unterschiede zwischen dem C-Makro-
Headerfile "libraries/mui.h" und dem Chunk MUI-WINDWLAYOUT besprochen.
Eigentlich sieht so eine Deklaration in der gadget-Datei genauso aus wie
im C-Quelltext. (Bitte mal in einer gadget-Datei nachsehen!)
Der Chunk MUI-WINDOWLAYOUT enth
lt jedoch nur den Auszug einer MUI-
Applikationsdeklaration, wo der Fensterinhalt erstellt wird. Madhouse
kennt die Gruppentypen HGroup, VGroup sowie ColumnGroup( Anzahl der Spal-
ten).
Die Gadgets werden deklariert, indem man den Gadget-Typ zwischen ein
Group,...End, schreibt und in Klammern die n
tigen Parameter
gibt (siehe @{"Gadget-Beschreibungen",link pm_gadgets}).
Die Gruppen erhalten einen Titel, indem man diesen mit in die Gruppen-
deklaration schreibt:
VGroup( "Laber" ), bzw. HGroup( "Bla" ), oder ColumnGroup( "S
lz", 2 ).
Jede Gruppen- oder Gadgetdeklaration wird in eine Zeile geschrieben,
immer von einem Komma gefolgt. Auch die letzte Zeile mu
mit einem
Komma abgeschlossen werden.
Soll man einen Buchstaben angeben, der zur Tastatursteuerung von Gadgets
benutzt werden soll, so mu
dieser in Anf
hrungszeichen eingeschlossen
sein und nicht in Hochkommas, wie in C sonst
blich.
Diese Beschreibung reicht nat
rlich noch nicht allein aus, um ein MUI-
BlankerPrefs-Fenster zu erzeugen. Deshalb solltet Ihr noch die beiden
unteren Kapitel (Gadgets, Gruppen) lesen.
@endnode
@node pm_start "MUI von Null auf Hundert f
r MUI-Greenhorns."
Damit Ihr die Erstellung einer MUI-Oberfl
che schafft, mu
ich Euer Hirn
erstmal etwas durchsch
tteln. Denn aus dem normalen Programmiereralltag
seid Ihr absolute und pixelgenaue Positionierung von Gadgets und anderen
grafischen Dingen gewohnt. Und jetzt kommt da einer daher, der Euch er-
ren will, wie man eine komplette Oberfl
che ganz ohne Koordinaten
aufbaut. Nachdem ich Euch darauf hingewiesen habe, was Euch gleich er-
wartet, kommt jetzt Psycho-Trick Nummer 1:
Hier seht Ihr eine stilisierte Oberfl
+--+----------------------------------------+--+--+
| | Fenstertitel | | |
+--+----------------------------------------+--+--+
| Button 1 |
+-------------------------------------------------+
| Button 2 |
+-------------------------------------------------+
| Button 3 |
+-------------------------------------------------+
| Button 4 |
+-------------------------------------------------+
Beschreibt einfach verbal, was Ihr seht. Wie sind die vier Kn
pfe in diesem
Fenster angeordet? Na klar: untereinander. Oder anders ausgedr
ckt: verti-
Mit diesem kleinen Beispiel wird schon einmal deutlich, wie man Gadgets
ohne Angabe von Positionen anordnen lassen kann. Man sagt MUI: Die Gadgets
kommen untereinander. Au
erdem sagt man MUI, was die Gadgets sind, also
blichen Beschreibungen (Cyclegadget, was sind die Cycleeintr
ge, was
ist der Wertebereich eines Sliders u.s.w.).
Daraus kann man sich ja schon ableiten, was wohl die zweite Anordnungsform
sein wird: horizontal, also nebeneinander. Diese Anordnungsformen werde
ich demn
chst als "Gruppen" bezeichnen. Wir h
tten da also horizontale und
vertikale Gruppen.
Aber das reicht ja noch lange nicht. Schlie
lich sind Oberf
lche meist
viel komplizierter. Deshalb gibt es ein weiteres Feature:
neben normalen Gadgets k
nnen die Gruppen noch weitere Gruppen enthalten.
<Lange Denkpause.>
Wie sieht also das oben dargestellte Fenster aus, wenn wir Anstelle von
Button 3 eine horizontale Gruppe mit zwei Buttons setzen? Das solltet
Ihr Euch jetzt mal auf Papier aufzeichen. Die L
sung ist folgende: @{" ",link pm_solv}.
rlich k
nnen die Untergruppen noch Unteruntergruppen enthalten, so
geht das dann weiter bis in alle Ewigkeit. Damit kann man dann schon eine
Menge anstellen. In der Regel arbeitet man aber nicht nur mit Buttons,
sondern viel mehr mit allen anderen Gadgettypen.
Und die anderen Gadgettypen bestehen nicht nur aus dem Gadget selbst, son-
dern auch aus dem Text davor, der das Gadget beschreibt. Dieser Text,
der z.B. dem "Blanker wechseln/Exchange Blanker"-Checkmark erst seinen Na-
men gibt, nennt man Label.
r viele Gadgets kennt Madhouse eine Kurzform, die nicht nur das Gadget
selbst, sondern auch das entsprechende Label davor erzeugt. Diese Kurz-
formen verwendet man aber in der Regel sehr selten.
Der Grund daf
r ist, da
alle Gadgets verschiedene Breiten und Ausdehnungs-
glichkeiten haben, und da
MUI die Gadgets von z.B. einer horizontalen
Gruppe immer zur Mitte der Gruppe zentriert. Will man drei Slider
einander erzeugen, die ja wahrscheinlich mit drei unterschiedlich langen
Labels beschriftet werden, so gleicht keine linke Sliderkante der anderen.
Man hat den Eindruck, da
die Gadgets wild umherfliegen.
Um die Oberf
chen also sch
ner zu machen, bietet MUI neben den horizon-
talen und den vertikalen Gruppen noch die Spalten- bzw. die Column-
Gruppen an. Wie hat man sich das vorzustellen? Eine Column-Gruppe steht
nicht einfach so da und wird von oben nach unten gef
llt, sondern sie
hat eine Spaltenanzahl. Eine Column-Gruppe hat eine Struktur wie Karo-
Papier, die K
stchen werden von links nach rechts ausgef
llt. Wenn die
Spaltenanzahl erreicht ist, erzeugt die Column-Gruppe die n
chste
Zeile. Hier kommt ein Fenster mit einer Column-Gruppe mit zwei Spalten.
Dieser Column-Gruppe wurden folgende Objekte zugeordnet:
ein Label, ein Slider, ein Label, ein Slider, ein Label, ein Cycle-Gadget.
+--+----------------------------------------+--+--+
| | Fenstertitel | | |
+--+----------------------------------------+--+--+
| Label 1 | Slider |
+-------------------------------------------------+
| Label 2 | Slider |
+-------------------------------------------------+
| Label 3 | Cycle |
+-------------------------------------------------+
Aber wie w
rde sowas denn nun eigentlich in der Gadget-Datei aussehen?
Zuerst mal der ungef
hre MUI-CHUNK f
r das erste Beispiel (eine einfache
horizontale Gruppe mit vier Buttons):
CHUNK:MUI-WINDOWLAYOUT
VGroup,
Button1,
Button2,
Button3,
Button4,
Hier werden einer vertikalen Gruppe (VGroup) vier Buttons zugeordnet.
Das End "schlie
t" diese Gruppe. Hinter jeder Zeile steht ein Komma,
trotzdem darf man diese Ausdr
cke nicht in einer Zeile zusammenfassen.
Die zugeordneten Buttons r
ckt man ein paar Zeichen ein, damit klar
wird, da
die Buttons zu dieser Gruppe geh
ren. Man sagt auch: "Die Buttons
sind Kinder der VGroup."
Mit der VGroup (oder HGroup, falls die Gadgets nebeneinander geh
und dem End verh
lt es sich wie mit den Klammern in einem Text, so geh
einer Gruppe immer das End, was in derselben Spalte steht. Madhouse liest
das aber nicht an der Spaltennummer ab, sondern macht es anders (was ich
hier aber nicht auch noch erk
ren will). Deshalb mu
man nichts einr
cken,
aber es ist doch bedeutend
bersichtlicher.
Und was ist nun mit der Column-Gruppe von eben? Da kommt sie:
CHUNK:MUI-WINDOWLAYOUT
ColumnGroup( 2 ),
Label( "_Label 1" ),
Slider( "l", 1, 10 ),
Label( "L_abel 2" ),
Slider( "a", -5, 20 ),
Label( "La_bel 3" ),
Cycle( "b", "Erster Eintrag|Zweiter Eintrag|Dritter Eintrag" ),
Das ist schon viel Stoff, oder? Nach dem Chunk-Header
"CHUNK:MUI-WINDOWLAYOUT", der Madhouse sagt, da
hier die MUI-Beschrei-
bung losgeht, folgt die Column-Gruppe mit den zwei Spalten, wie in der
Skizze oben. Die folgenden Kinder der Gruppe werden von links nach rechts
und von oben nach unten in die Spaltengruppe eingef
gt. Man sollte darauf
achten, da
die Spaltenzahl Teiler der Anzahl der Kinder einer Column-
Gruppe ist. Anders ausgedr
ckt: wir haben sechs Kinder f
r eine Gruppe mit
zwei Spalten. 6 durch 2 geht glatt auf, 7 durch 2 z.B. nicht. Eine Column-
Gruppe mu
mlich immer bis in die letzte Spalte aufgef
llt sein. Wenn
einem das nicht pa
t, behilft man sich anders, aber dazu sp
Oben k
nnen wir noch sehen, wie man ein Label erstellt. (Dieses Beispiel
nnte man schon so wie es dasteht in eine Gadget-Datei schreiben.)
Also, in die Anf
hrungszeichen kommt der Text, der dann in das betreffende
stchen" der MUI-Gruppe eingef
gt wird. In diesem Text kann ein Under-
score ("_") vorkommen, der angibt, da
das nachfolgende Zeichen unter-
strichen wird.
Das ist auch n
tig, damit der Benutzer wei
, mit welcher Taste er ein
Gadget steuern kann. MUI ist n
mlich extrem tastaturfreundlich.
Der nachfolgenden "Deklaration", ein Slider, wird schon als erstes Argu-
ment der Buchstabe
bergeben, mit dem der Slider gesteuert wird. Diese
Buchstaben sind immer klein zu schreiben. Dann kommen Minimal- und
Maximalwert des Sliders, also reicht der erste Slider von 1 bis 10.
Nun wird der n
chste Slider beschriftet. Er hat den Buchstaben "a", und
sein Wertebreich geht von -5 bis 20.
Jetzt kommt noch das dritte Label, Hotkey "b". Dann kommt etwas Neues:
die Deklaration eines Cycle-Gadgets. Wie auch beim Slider wird zuerst der
Hotkey angegeben, dann folgen die Eintr
ge des Cycle-Gadgets, getrennt
durch "|".
Wo wir gerade bei den Hotkeys, also den Tastatursteuerungsbuchstaben f
Gadgets, sind: Diese Hotkeys d
rfen nur einmal vorkommen. "Verbotene"
Buchstaben sind o, t und c: Damit werden schon die Gadgets am unteren
Rand des BlankerPrefs-Fensters gesteuert.
War nicht vorhin davon die Rede, da
man die Gruppen schachteln kann?
Wann ben
tigt man denn sowas?
Sicherlich habt Ihr gemerkt, da
MUI die Gadgets nicht nur automatisch,
sondern auch dynamisch anordnet. So ziemlich jedes MUI-Fenster hat ein
en-Gadget, und die Gadgets passen sich automatisch der neuen Fenster-
e an, nachdem man es benutzt hat.
Viele MUI-Fenster lassen sich nur in die Breite ziehen, die vertikale
t sich weniger oft ver
ndern (an einigen BlankerPrefs-Fenstern
ausprobieren).
Warum eigentlich? Nun, jedes MUI-Objekt (also vor allem die Gadgets, die
Gruppen auch, aber von denen reden wir jetzt lieber nicht auch noch)
hat eine minimale und maximale H
he und Breite. Ein Slider, ein String-
gadget, ein Cyclegadget und noch ein paar andere Sachen haben eine feste
he. Klar, ein horizontaler Slider kann ja nur breiter werden, w
rde er
her, w
rde das komisch aussehen. Bei vertikalen Slidern, die sich von
oben nach unten slidern lassen, ist es umgekehrt.
Listen haben aber sowie horizontale als auch vertikale Vergr
erungsfrei-
heit. Will man mehr von ihnen sehen, zieht man das Fenster einfach auf.
Checkmarks stehen als Objekt da und lassen sich nicht gr
er und kleiner
machen. Also lassen sich viele MUI-Fenster nur horizontal vergr
ern, weil
die meisten Gadgets vertikal beschr
nkt sind.
Wir hatten aber eigentlich gerade das Problem f
r die L
sung gesucht, bei
der man die Gruppen schachtelt. Nun stellt Euch mal vor, im letzten Bei-
spiel w
rde man das Cycle-Gadget durch ein Checkmark-Gadget ersetzen.
Die beiden Slider w
rden ihre Minimalbreite bekommen (beim Versuch, sich
ngenm
ig an das kleine Checkmark-Gadget anzupassen), und das Fenster
re jetzt gar nicht mehr vergr
erbar.
Also machen wir das Checkmark seitlich ausziehbar. Das geht aber nicht.
Also ersetzen wir das Checkmark durch eine horizontale Gruppe, die
ein Checkmark und einen Slider enth
lt. Nun w
re das Fenster wieder
horizontal vergr
erbar, weil die ColumnGruppe wieder vergr
erbar
wurde, weil ihre Kinder (die Slider und die HGroup) vergr
erbar sind. Die
HGroup wurde
brigens vergr
erbar, weil EINS ihrer Kinder (n
mlich der
Slider) vergr
erbar ist.
Die Labels sind nicht vergr
erbar. Genau m
te es also hei
Die Column-Gruppe ist horizontal vergr
erbar, weil mindestens in einer
Spalte alle Kinder der Gruppe vergr
erbar sind.
Nun w
rden aber alle MUI-Applikationen h
chst seltsam aussehen, wenn man
immer Sliders als F
llstoff verwenden w
rde. Deshalb gibt es ein Objekt,
das nach nichts aussieht und das auch nichts kann, das aber in alle Rich-
tungen ausziehbar ist. Wenn n
tig, bis nach Tokio.
Dieses Objekt hei
t "HVSpace", also w
rtlich
bersetzt, horizontaler
und vertikaler Raum.
Also greifen wir wieder das letzte Beispiel aus. So w
rde die Skizze aus-
sehen, wenn man das Cycle-Gadget durch eine horizontale Gruppe mit
Checkmark und HVSpace ersetzen w
+--+------------------------------------------+--+--+
| | Fenstertitel | | |
+--+------------------------------------------+--+--+
| (Label 1) | (Slider---------------------------) |
+---------------------------------------------------+
| (Label 2) | (Slider---------------------------) |
+---------------------------------------------------+
| (Label 3) | (Checkmark) | (HVSpace------------) |
+---------------------------------------------------+
Die Objekte haben jetzt Klammern und Spiegelstriche bekommen, um anzudeu-
ten, wie ihre Ausdehungsm
glichkeiten sind.
Und wie sieht der MUI-WINDOWLAYOUT-Chunk aus? Voil
(Anm. des Autors: 4
Jahre Franz
sischunterricht hatten wenig zur Folge.
Aber den acent von voil
kann ich schon richtigherum setzen, ohne im
dictionnaire nachschlagen zu m
ssen.)
CHUNK:MUI-WINDOWLAYOUT
ColumnGroup(2),
Label( "_Label 1" ),
Slider( "s", 1, 10 ),
Label( "L_abel 2" ),
Slider( "a", -5, 20 ),
Label( "La_bel 3" ),
HGroup,
CheckMark( "b" ),
HVSpace,
End,
Mit diesem Beispiel sollte nun der MUI-Groschen gefallen sein. Mit HV-
Space k
nnen auch ColumnGruppen aufgef
llt werden, bei denen man nicht
jede Spalte einer Zeile ben
tigt.
Eine ausgiebige Lekt
re der mitgelieferten gadget-Dateien ist sicher auch
hilfreich, falls man mit MUI einen bestimmten Effekt erzeugen will, dessen
technische L
sung einem nicht einf
rlich war das jetzt noch nicht die gesamte MUI-Anleitung, aber erst-
mal das Grundwissen zum Layout-Prozess. Die einzelnen Gadgettypen und
noch eine Spezialit
t bei den Boxen werden in den n
chsten Kapiteln
beschrieben.
Wie auch das Programmieren, kann das Erzeugen von MUI-Windowlayout-
Chunks nicht "auf dem Trockenen" erlernt werden. Etwas
bung geh
auch dazu.
Wer das Grundprinzip verstanden hat, der hat es nun auch schon leichter,
in die MUI-Programmierung von richtigen Programmen einzusteigen. Allerdings
schreibt man dann diese Group-Geschichten in den Programmcode und l
t sie
von einem waschechten Compiler interpretieren, nicht von einem kleinen
Programm namens MadhouseConfigEd. Wo da der Unterschied liegt? Nun, ein
Compiler entsteht in mehreren Mannjahren Arbeit, der Madhouse-Programmteil
zum Lesen des MUI-WINDOWLAYOUT-Chunks entstand in einer halben Woche.
Deshalb sei es mir verziehen, wenn ich
a) nicht jedes Feature in den Interpreter eingebaut habe. Es lassen sich
keine Page-Gruppen erzeugen, die Ausdehnungs-Gewichte der Objekte stehen
fest auf 100, und es gibt auch keine CustomClasses (was wohl meilenweit
bertrieben w
re) und manche Spezialgadgets fehlen auch. Die wichtigsten
Dinge k
nnen aber problemlos erzeugt werden, deshalb sehen die Blanker-
Prefs-Fenster auch genauso gut aus wie "richtige" MUI-Appliationen wie
Madhouse und alle anderen.
b) die Fehler in einer gadget-Datei nicht peinlich genau abfrage. Madhouse
ist mir zwar infolge von solchen Fehlern noch nie abgest
rzt, und das
wird es sicher auch nicht. Aber es gibt nicht zu jedem Fehler eine
Fehlermeldung, denn da h
tte ich ja fast alle der 260 Fehler, die mein
C-Compiler melden kann, auch auf die gadget-Dateien
bertragen m
ssen.
Aufmerksam wird man auf die Fehler sowieso, und finden tut man sie auch
schnell, denn der MUI-Chunk ist ja immer nur ein paar Zeilen lang.
brigens arbeitet auch Vionas EGS auf dem Boxenprinzip, die Gadgets werden
hnlich wie bei MUI angeordnet. EGS wurde auf dem Amiga durch die vielen
Grafikkarten, mit denen es ausgeliefert wird, bekannt. Deshalb gibt es
wohl auch kaum EGS-Anwendungen, die nichts mit Grafik zu tun haben.
@endnode
@node pm_solv "Die L
sung"
+--+----------------------------------------+--+--+
| | Fenstertitel | | |
+--+----------------------------------------+--+--+
| Button 1 |
+-------------------------------------------------+
| Button 2 |
+-------------------------------------------------+
| Button A | Button B |
+-------------------------------------------------+
| Button 4 |
+-------------------------------------------------+
@endnode
@node pm_groups "Die Gruppen"
rlich erkl
re ich hier nicht das gesamte Boxenprinzip erneut. Das steht
ja schon alles im Greenhorn-Kapitel.
@{B}HGroup und HGroup( "Gruppentitel" )@{UB}
Die HGroup, die ihre Kinder ja
bereinander anordnet, kann auch umrahmt
werden, und wird damit sichtbar. In diesem Rahmen wird dann ein Gruppen-
titel dargestellt, der die Gruppe sozusagen
berschreibt.
Will man so ein Ding erzeugen, benutzt man die HGroup so wie es in der
berschrift steht.
Dasselbe geht auch mit VGroups.
@{B}ColumnGroup( x ) und ColumnGroup( "Gruppentitel", x )@{UB}
x steht nach wie vor f
r die Anzahl der Spalten.
Wie auch die anderen Gruppen kann die ColumnGroup einen Titel bekommen.
@endnode
@node pm_gadgets "Die Gadgets"
@{B}Einige Standard-Bezeichner in diesem Kapitel@{UB}
- @{I}Taste@{UI} enth
lt einen Kleinbuchstaben, der angibt, mit welcher Taste
auf dem Keyboard des Computers ein Objekt gesteuert werden kann.
Beispiel: Slider( "a", 5, 10 ) erzeugt einen Slider, der mit der Taste A
gesteuert wird. Die Tasten "o", "c" und "t" sind bereits f
r die Standard-
Gadgets am unteren Rand des BlankerPrefs-Fensters reserviert und k
daher nicht benutzt werden.
- @{I}Bezeichnung@{UI} steht f
r einen Text, auf der linken Seite des betreffenden
Gadgets angezeigt werden soll. Dieser Text soll das Gadget n
her erl
utern.
Beispiel: LabelCycle( "Color _selection", "s", "Red|Green|Blue" ) w
ein Cycle-Gadget herstellen, auf dessen linker Seite sich der Text "Color
selection" befindet, bei dem der Buchstabe "s" unterstrichen wird. Das ist
tig, damit der Benutzer wei
dieses Cycle-Gadget mit dem Buchstaben
"s" gesteuert wird.
@{B}Slider( Taste, Minimalausschlag, Maximalausschlag )@{UB}
erzeugt einen Slider. Minimal- und Maximalausschlag bezeichnen den Aktions-
Radius des Sliders, inklusive dieser beiden Werte (d.h., da
Minimalaus-
schlag selbst ist auch noch anw
hlbar ist).
@{B}LabelSlider( Bezeichnung, Taste, Minimalausschlag, Maximalausschlag )@{UB}
wie oben, jedoch zus
tzlich mit einem Label auf der linken Seite.
@{B}CheckMark( Taste )@{UB}
stellt ein H
kchengadget her.
@{B}Cycle( Taste, Auswahlm
glichkeiten )@{UB}
stellt ein Cycle-Gadget mit mehreren Eintr
gen her. "Auswahlm
glichkeiten"
ist eine Zeichenkette, die alle Eintr
ge enth
lt. Ein Beispiel daf
"RGB|HSV|CMYK". Der Vertikalstrich "|" trennt die Eintr
ge. MUI beginnt das
hlen der Eintr
ge (wie sich das f
r einen Computer geh
rt) mit Null,
wenn also RGB der aktive Eintrag ist und der User auf "Test" klickt, steht
eine "0" in der prefs-Datei.
@{B}LabelCycle( Bezeichnung, Taste, Auswahlm
glichkeiten )@{UB}
wie oben, jedoch zus
tzlich mit einem Label auf der linken Seite.
@{B}String( Taste, L
nge )@{UB}
erzeugt ein String-Gadget. Es lassen sich maximal so viele Zeichen ein-
geben, wie bei "L
nge" angegeben. Wieder ist die Obergrenze f
r eine
Stringl
nge 500, was dar
ber geht wird automatisch auf 500 gesetzt.
@{B}LabelString( Bezeichnung, Taste, L
nge )@{UB}
wie oben, jedoch zus
tzlich mit einem Label auf der linken Seite.
@{B}Label( Bezeichnung )@{UB}
erlaubt eine bessere Plazierung der Objekte. Wenn Label und Objekt
getrennt werden (macht man normalerweise so), dann schlie
en die
Gadget-Rahmen b
ndig ab. Man ben
tigt dann einen Gadgettyp ohne
Label... am Anfang und dieses Label-Objekt.
Bezeichnung ist diesmal alles, aus was das Objekt besteht.
@{B}LLabel( Bezeichnung )@{UB}
wie oben, jedoch wird dieses Label nicht rechts ausgerichtet, sondern
links. Das ist praktisch, wenn man hinter einen Slider noch eine Angabe
klemmen will. Sonst sollten alle Objekte links beschriftet werden, nur
bei den CheckMarks bin ich mir da nicht so sicher (da macht auch eine
Beschriftung auf der rechten Seite Sinn). Ein Beispiel f
r linksb
ndige
Labels findet sich in der gadget-Datei von Waves.
@{B}HVSpace@{UB}
der ber
hmte Platzhalter, wie viele andere Dinge schon bekannt aus dem
Vorkapitel.
@{B}HBar@{UB}
Eine sehr elegante Sache, die die Gruppen-Rahmen manchmal ersetzen kann:
dieses Objekt zeichnet einen waagerechten Strich an seiner Position,
und sollte nur in horizontalen Gruppen zur Trennung von Funktionen benutzt
werden.
@{B}VBar@{UB}
wie oben, jedoch in der vertikalen Ausf
hrung. Eine VBar l
t sich gut
im BlankerPrefs-Fenster von Stars beobachten.
@endnode
@node pm_mpo "Der CHUNK:MUI-PREFSORDER"
"Wie kann MUI nur mit einem Chunk auskommen?", werden viele schon gefragt
haben. So ganz geht das doch nicht. Aber jetzt wieder zuerst ein Problem.
Ganz oben, in der Erkl
rung wie man einen Blanker zu schreiben hat, schrieb
ich, da
Madhouse die Einstellungen der Gadgets in der Reihenfolge in die
prefs-Datei abspeichert, in der die Gadgets im CHUNK:GADGETS angegeben wur-
den. Und im CHUNK:MUI-WINDOWLAYOUT? Da ist es genauso. Allerdings haben wir
da ein gaaaanz kleines Problem: Man kann mit diesem MUI-Chunk nicht ein
Gadget in die obere Fensterecke legen und dann seine Einstellung zuletzt
auslesen wollen. Nat
rlich k
nnte man jetzt den Programmtext
ndern, und
mir f
llt gerade ein, wie sinnlos diese Funktion ist, aber man kann eine
bestimmte Funktion von Madhouse benutzen, n
mlich den CHUNK:MUI-PREFSORDER.
In diesem Chunk wird die Reihenfolge angegeben, mit der die Einstellungen
in die prefs-Datei geschrieben werden. Bei Waves und Stars habe ich diesen
Chunk ben
tigt. Auch Note enth
lt einen.
Dazu mu
man nun zuerst jedem Gadget einen internen Namen geben, zum Bei-
spiel so:
CHUNK:MUI-WINDOWLAYOUT
VGroup,
LLabel( "Ein Ausschnitt aus der Stars-gadget-Datei." ),
ColumnGroup( 2 ),
Label( "_Maximum" ),
Maximum = Slider( "m", 1, 8 ),
Label( "M_inimum" ),
Minimum = Slider( "i", -7, 1 ),
Label( "C_anges" ),
Changes = Slider( "a", 0, 15 ),
Label( "_Start" ),
Start = Slider( "s", -7, 8 ),
End,
Normalerweise w
rde die prefs-Datei so aussehen:
Wert von Maximum
Wert von Minimum
Wert von Changes
Wert von Start
Duration-Zeit in Minuten
Pfad auf das Verzeichnis des Blankers
Und jetzt kommts: schreibt man noch
CHUNK:MUI-PREFSORDER
Changes, Start, Minimum, Maximum
dann sieht die prefs-Datei schon ganz anders aus:
Wert von Changes
Wert von Start
Wert von Minimum
Wert von Maximum
Duration-Zeit in Minuten
Pfad auf das Verzeichnis des Blankers
Naja, sowas braucht man wohl sehr selten bis gar nicht... Wichtig ist aber
noch, da
als "interne Bezeichner" nur ganz gew
hnliche Buchstaben in
Frage kommen, nicht aber Zahlen und andere Spezialit
@endnode
@node addon "Anhang"
@{"A Arrrggh: Bekannte Probleme ",link problems}
@{"B Die Autoren und das: Copyright ",link authors}
@{B}@{"C Madhouse ist toll: Registrieren leicht gemacht. ",link registration}@{UB}
@{"D Die Revolution: MUI ",link mui_info}
@{"E Nutzlos
: alle hier verwendeten Smileys",link smileys}
@endnode
@node problems "Bekannte Probleme"
@{B}Probleme - Kapitel I: Probleme, die von einer Programmiersprache
namens AMOS (
ber 43.655 versch. Befehle...) erzeugt werden:@{UB}
@{U}Probleme mit VGA-Monitoren@{UU}
Genialerweise
ffnen AMOS-Programme keinen normalen Intuition-Screen.
Wer einen VGA-Monitor ohne ScanDoubler o.
. sein eigen nennt, der kann
zwar die Blanker, die von mir in C++ geschrieben wurden, mittels eines
Screen-Promoters umpatchen; aber die AMOS-Blanker von Aicke m
ssen hier
klein beigeben. In diesem Fall hat Madhouse nur sechs Blankmodes, sorry.
Falls tats
chlich mal die AMOS-AGA-Version erscheinen sollte, f
r die
auch das
ffnen von normalen Screens versprochen wurde, wird Aicke
alle AMOS-Blanker darauf anpassen. Falls Aicke die Programmiersprache
wechseln sollte (ist noch unwahrscheinlicher), h
ttet Ihr und ich
weniger Probleme. Madhouse mu
mlich extra abgestimmt werden,
damit AMOS die erzeugten Textdateien lesen kann.
@{U}Probleme mit MousoMeter@{UU}
MousoMeter macht leider ebenfalls Probleme mit AMOS-Programmen, was sich
ert, da
MousoMeter wie wild Kilometer z
hlt. Das bricht jeden High-
score. Der Grund ist wohl, da
AMOS AMOS ist. (Anders kann ich mir das
nicht erk
ren.) Spitze, AMOS!
Abhilfe: AMOS-Blanker inaktivieren.
@{B}Probleme, die durch inkompatible Programme entstehen (auch AMOS..)@{UB}
@{U}Probleme mit AMOS und Protracker (und vielleicht mit anderen Tracker-@{UU}
@{U}Sound-Editoren, nicht aber mit MED)@{UU}
Manche Programmierer wollen wohl die Grafikausgabe beschleunigen, indem
sie einen Screen
ffnen, der kein Intuition-Screen ist. Diesen k
nnt Ihr
nicht wie gew
hnlich umschalten, au
er wenn diese Programmierer die Tasten
<linke Amiga + n> (und +m) selbst abfragen. Na ja, jedenfalls kann man die-
ses Etwas nicht nach hinten bringen, indem man selbst einen Intui-Screen
ffnet. Deshalb werden die Blanker FlyingToasters, Stars, FireWorks, Waves,
Socher und Shuffle (die ich in C schrieb) HINTER AMOS und Protracker ange-
zeigt. Die anderen Blanker, die Aicke in AMOS schrieb (paradox, oder?)
nnen aber vor AMOS und Protracker angezeigt werden. Also d
rfen nur diese
Blanker bei Benutzung von AMOS und Protracker angew
hlt sein.
Weiterhin funktionieren mit obigen Programmen der Black Background und
der Pa
wortscreen nicht, aus demselben Grund.
@{B}Probleme, die in Sondersituation 48d entstehen:@{UB}
@{U}Probleme mit einer resetfesten Ram-Disk,@{UU}
@{U}die als RAM: gemountet ist@{UU}
Dieser Tip stammt von Aicke, und vielleicht bleibt er auch der einzige
User, der gar keine nicht-resetfeste Ram-Disk hat, daf
r eine reset-
feste SD0: oder VD0:, die
ber RAM: angesprochen wird.
Wer also Madhouse bei jedem Systemstart automatisch aufrufen l
(z.B. mit der WBStartup-Schublade) und wer ein Ger
t namens RAM: hat
welches nach einem Reset NICHT wieder leer ist, der hat ein Problem:
Madhouse wird nach einem Reset beim Start schon die Schublade
RAM:Madhouse_Storage vorfinden und denken, es w
re 2x gestartet worden.
Dieses Problem kann man nun umgehen, indem man VOR dem Start von
Madhouse dieses Shell-Kommando ausf
hren l
t, indem man es z.B. in die
S:User-Startup eintr
delete >NIL: RAM:Madhouse_Storage ALL
Beachtet bitte, da
es nicht m
glich ist, gar kein RAM:-Device zu haben.
@endnode
@node authors "Die Autoren und das Copyright."
@{FG Highlight}@{B}Eine Art History-File: kleiner Geschichtsunterricht@{UB}@{FG Filltext}
Wir brauchten neunzehn Monate, um Madhouse und die Blankmodes zu entwik-
keln. Aicke hat fr
her angefangen, weil mein Computer damals gerade in
Reparatur war. So entstanden einige seiner Blankmodes fr
her. Madhouse
wurde von uns schon fr
her erdacht, denn immer, wenn wir einen modularen
Screenblanker in PD-Serien gesehen hatten, gefiel er uns nicht richtig.
Wir hatten viele Ideen f
r ein besseres Hauptprogramm, die gr
tenteils
in Madhouse verwirklicht wurden. Doch am
rgerlichsten waren oft die
Blankermodule, so kann man sie bei einigen Blankern gerade noch als
Beispielprogramm durchgehen lassen (dabei waren die Dinger echt dazu
gedacht, die Leute zu begeistern)...
Jedenfalls k
nnen wir die Urspr
nge von Madhouse nicht mehr richtig
nachvollziehen. Eine Kritzelei, die schon etwas aussieht wie das
Hauptfenster befindet sich noch in meinem alten Deutschordner und hat
das Datum 6.8.93. Damals hie
meine Programmiersprache noch GFA-Basic.
Im "Entwicklertagebuch" des Hauptprogramms kann ich aber den Beginn
noch ablesen: am 25.1.94 entwarfen Aicke und ich das Design des Haupt-
fensters. Der Name von Madhouse war zu dieser Zeit nicht Madhouse,
sondern "BlackHole". Diesen Namen gab es aber schon. So hatte Aicke in
den folgenden Wochen diverse Einf
lle f
r neue Namen. Am 26.2. konnten
wir uns dann f
r "Madhouse" entscheiden. Alternativen waren z.B "Joke-
Box" oder "Monitor-Holidays".
Wie jedes Programm hatte auch Madhouse viele Bugs. Fast zur Verzweiflung
trieb mich ein ganz hartn
ckiger, der Madhouse nach Bet
tigung des Remove-
Buttons zum Abst
rzen brachte. Dabei st
rzte der Computer genau (das
konnte ich kontrollieren) beim Aufruf der exit()-Funktion ab, der ein
Programm beendet. Nach mehreren Wochen fiel mir dann auf, da
es an der
Stackgr
e von Madhouse lag...
@{FG Highlight}@{B}Arbeitsteilung: Entwicklung beim Einen, Abst
rze beim Anderen...@{UB}@{FG Filltext}
(war umgekehrt nicht der Fall... AMOS als absturzfreie Sprache??!)
Von Aicke stammen 62,5% der Blanker. Wahrscheinlich kann man an seinen
Blankern und auch an den anderen Teilen Madhouses erkennen, da
er ein
echter Perfektionist ist. Das hat es einerseits nicht einfach gemacht,
mit ihm zu arbeiten, aber es hat Madhouse oft entscheidend verbessert.
So hat er in allen Dingen, die zu Madhouse geh
ren, seine Spuren hinter-
lassen: ob er nun f
nf Pixel an der kleinen Diskette ge
ndert hat, die
im Ask-For-Disk-Fenster erscheint oder ob er eine gute Idee f
r FireWorks
hatte. Ideen hat er auch viele, so da
er schon neue Blankmodes in Vor-
bereitung hat. Die AMOS-Demo ist auch von ihm.
Madhouse ist mein zweites C-Programm (eigentlich C++), das Erste waren
die FlyingToasters. Von mir kommt auch die englische und deutsche Anlei-
tung. In der Englischen werden viele Fehler sein, in der Deutschen viele
Abweichungen vom Thema... (Leider seht Ihr nun gar nichts von der engl.
Anleitung, weil die f
r eine deutsche Zielgruppe nun doch nicht mehr n
tig ist.) Da das Einsteigen in eine Sprache wie C recht schwierig ist,
danke ich allen die durch ihre Quelltexte im PD-Bereich etwas Licht in
das gro
e Compilerdunkel brachten. An die seitenlangen Compilerfehler
kann ich mich noch gut erinnern. Die C-Demo habe ich auch geschrieben,
das war meine erste echte Konfrontation mit dem ANSI-C-DosLib-File-I/O.
Zusammen haben wir einen Vorteil anderen Programmieren gegeb
ber, die
allein arbeiten: Wir haben verschiedene Computer. Damit kann man
Programme besser auf Fehlerfreiheit testen, den die Betriebssysteme
2.0 / 3.0 reagieren bei Programmfehlern so gut wie immer unterschiedlich.
@{FG Highlight}@{B}Blick in die Glaskugel@{UB}@{FG Filltext}
In Zukunft werden hoffentlich neue Blanker erscheinen. Die m
ssen dann
nicht unbedingt von uns sein, denn mit der mitgelieferten Dokumentation
(in dieser Anleitung) kann so ziemlich jeder selbst einen Blanker her-
stellen. Eine Idee w
re noch ein Sound-Teil, Madhouse k
nnte Musik-
Module abspielen w
hrend die Blanker laufen. Meine wichtigste Planung
r die Zukunft war das MUI-Interface f
r Madhouse. Wie Ihr sicherlich
schon gemerkt habt, haben die MUI-Funktionen schon den Sprung in diese
Version geschafft.
Wir haben schon eine Menge Ideen f
r neue Blanker. Teilweise ist schon
Grafik fertig. Auch manche vorhandenen Blanker sind noch Verbesserungs-
hig. Falls es einen Geschwindigkeitszuwachs gibt (und das hoffe ich
doch) werden die FlyingToasters mit Bobs arbeiten. Ein Aquarium w
re auch
langsam f
llig, oder fangen wir doch lieber mit einer anderen Idee an?
Madhouse ist Shareware, der Betrag ist 20 DM. Im Registrationskapitel
(@{"Anhang C",link registration}) k
nnt Ihr alles
ber die Registration
erfahren.
Wenn Ihr einen Bug findet, bitte schreibt uns! Wenn jemand einen guten
Blanker geschrieben hat, soll er/sie (?) ihn nicht nur f
r sich behalten,
sondern auch ver
ffentlichen! Es w
re wirklich super, wenn auch andere
Programmierer unser System nutzen w
rden.
@{FG Highlight}@{B}Unser Input-Device: schreibt uns mal!@{UB}@{FG Filltext}
Ihr k
nnt uns Ideen, Grafiken und Code senden, dann versuchen wir, was
draus zu machen. Wenn Ihr eine Antwort wollt, legt bitte genug Brief-
marken bei (am besten deutsche oder internationale). Wer wei
, wieviel
da ankommt... (Wahrscheinlich gar nichts, sowas kennt man ja.)
Wenn Ihr uns wegen Bugs schreibt, dann erkl
rt bitte peinlich genau
WAS passiert ist, WIE Ihr das geschafft habt und WELCHE anderen Sachen
im Hintergrund liefen und welchen Computer Ihr benutzt. Desweiteren ben
tigen wir eine genaue Beschreiben der Pflanzen im Computerraum.
Am besten Ihr versucht es auch ohne Tools und mit Eurer Original-
Workbench, bevor Ihr uns mit Back-Beschreibungen zudr
hnt... Nat
rlich
sind wir auch froh, wenn wir Bugmeldungen erhalten, aber andere Dinge
rden uns halt mehr freuen - verst
ndlich, oder?
Leider verf
gen wir mangels Modem
ber keine E-Mail-Adresse.
Aicke Schulz
Neudeckerweg 118
D-12355 Berlin
Telefon: 030 (Berlin) / 664 48 22
Carsten Jahn
Kuckucksruf 34
D-16761 Stolpe-S
Vielen Dank f
r den Brief!
rlich d
rfen auch die Credits, sprich Danksagungen nicht fehlen. Die
Blanker CrazyPixel, DigitalClock, Drops, Glitter, Memory, Note, Skyline,
SoftwareFailure, Thunder und Worldtime wurden mit der Programmiersprache
AMOS entwickelt. Die Blanker FireWorks, FlyingToasters, Shuffle, Soccer,
Stars und Waves sowie das Hauptprogramm wurden mit dem MaxonC++-Light 3
Compilerpaket erstellt und compiliert.
Madhouse und alle dazugeh
rigen Daten und Programme sind Copyright
1994-1995 Carsten Jahn und Aicke Schulz. Alle Rechte weltweit vorbehalten.
@{"MagicUserInterface",link mui_info} wurde von Stefan Stuntz entwickelt, die Rechte daf
liegen bei ihm.
+---------------------------------------------------------------+
| Wer Madhouse verf
lscht oder nachmacht, oder verf
lschte oder |
| nachgemachte Versionen in Umlauf bringt, wird mit Windows
| nicht unter zehn Stunden bestraft. |
+---------------------------------------------------------------+
rlich wird keinerlei Haftung f
r Sch
bernommen, die durch den
Gebrauch von Madhouse entstehen / entstanden sind.
r den Gebrauch von Windows
haften wir erst recht nicht.
Und w
rend ich hier die Zeile 3591 der Anleitung schreibe, verabschiede
ich mich und w
nsche allen Amiga-Usern ein langes, sch
nes Leben,
tolle Programme, neue Blanker, einen Multiscanmonitor und uns allen das
berleben des Amiga auf dem engen Markt der Hardwareplattformen.
@{I}@{B}Tsch
, bis zur n
chsten Anleitung,@{UB}
Euer Carsten.@{UI}
@endnode
## Mu
te wieder einer nachsehen, ob die Zeilennummer wirklich stimmt :-)
@node registration "Registration"
Seit eineinhalb Jahren haben wir Madhouse auf unseren Computern. Endlich
ist es uns gelungen, es einigerma
en fertigzustellen. Ein modulares System
kann zwar gar nicht fertig sein, schlie
lich k
nnten noch hunderte von
Blankern hinzukommen, aber die Hauptprogramme Madhouse und MadhouseConfigEd
sind langsam ausgereift. Nun sollte es jedem Amiga-User zug
nglich sein,
und wir hoffen wenigstens auf ein kleines Feedback.
Ohne das Keyfile, das jeder registrierte User von uns per Post erh
lt, l
sich Madhouse nicht dauerhaft benutzen. Ist es nicht vorhanden, werden die
Einstellungen in ENV: und ENVARC: nicht beachtet, also mu
nach jedem Start
mindestens der Pfad zu den Blankern neu eingestellt werden.
Nach der Registration erhaltet Ihr von uns eine Diskette, die eine Datei
namens Madhouse.key enth
lt. Diese solltet Ihr in Euer S: - Verzeichnis ko-
pieren. Sonst kopiert Ihr die niemandem! Sie enth
mlich Eure komplette
Anschrift, die Ihr 1. nicht im Keyfile
ndern solltet, sonst wird es nicht
mehr erkannt, und die Euch 2. sofort entlarvt, wenn sie einmal der Falsche
in die H
nde kriegt.
Um Euch registrieren zu lassen, ben
tigt Ihr:
- Das ausgef
llte Registrationsformalur. Dieses k
nnt Ihr einfach aus-
drucken und leserlich ausf
llen.
- Den Betrag von @{B}20 DM@{UB}, soviel kostet das. Dieser Preis ist doch
ugling-, Kleinkinder-, Jungliche-, Erwachsenen- und Seniorenfreundlich,
oder?
- Einen normalen Briefumschlag. Da steckt Ihr o.g. hinein.
- Eine 1DM-Briefmarke. Die klebt Ihr auf o.g. drauf.
- Einen Briefkasten in Eurer N
he. Da steckt Ihr o.g. hinein.
Mut geh
brigens nicht dazu - Ich habe schon dreimal Geld f
r solche
Zwecke mit der Post verschickt, nach Deutschland, nach Holland und nach
England, und immer hat es geklappt.
Wer das aber will, der kann das Geld auch
berweisen:
Aicke Schulz
Deutsche Bank, BLZ 100 700 00, Konto-Nr. 3565611
Bitte trotzdem das Formular ausf
llen und an uns schicken!
Als mordsm
igen Bonus garantieren wir den ersten zwanzig Bestellern, da
sie eine Diskette mit unserer Handschrift und Autogrammen erhalten!
(Schlie
lich lohnt es sich nicht, f
r 0 oder 4 Disketten Aufkleber zu
drucken...)
Alles klar?
Na, dann wollen wir mal den @{"Ausdruck starten" system "copy Registration_D.txt to PRT:"}.
@endnode
@node mui_info "Auch Madhouse benutzt das sagenhafte MUI."
This application uses
MUI - MagicUserInterface
(c) Copyright 1993/94 by Stefan Stuntz
MUI is a system to generate and maintain graphical user interfaces. With
the aid of a preferences program, the user of an application has the
ability to customize the outfit according to his personal taste.
MUI is distributed as shareware. To obtain a complete package containing
lots of examples and more information about registration please look for
a file called "muiXXusr.lha" (XX means the latest version number) on
your local bulletin boards or on public domain disks.
If you want to register directly, feel free to send
DM 30.- or US$ 20.-
to
Stefan Stuntz
Eduard-Spranger-Stra
80935 M
nchen
GERMANY
Stefan will uns damit sagen, da
die Oberf
che von Madhouse mit installier-
tem MUI v
llig frei von Euch gestaltet werden kann. Dem kann ich nur zu-
stimmen. MUI geh
rt zu den flexibelsten Programmen, die ich je gesehen
habe. MUI ist kein normales Programm, was man f
r einen bestimmten Zweck
benutzt. Jede entsprechend programmierte Anwendung kann es verwenden, und
dann profitiert der Anwender davon. In PD-Serien und Mailboxen findet man
die aktuelle Version von MUI, so richtig toll ist aber nur die unter der
oben genannten Adresse zu beziehende Vollversion, mit der man die Ein-
stellungen dauerhaft speichern kann. Sonst sehen die MUI-Anwendungen nach
jedem Reset wieder ganz normal aus.
@endnode
@node smileys "Alle in dieser Anleitung verwendeten Smileys"
Neben dem Standard-Smiley :-) wurde der Einsatz weiterer Arten in dieser
Anleitung n
tig. Die m
ssen nat
rlich noch entsprechend gedeutet werden:
==) Smiley mit Darth-Vader-Helm.
*-{:-) Smiley mit Bommelm
tze (Inspiration aus der Winterzeit).
) Smiley mit Designerbrille (und Knollennase).
:^) Smiley aus der isometrischen Perspektive.
Allen Smiley-Fans empfehle ich stark das Archiv misc/misc/SmileyV3.lha aus
dem AmiNet.
@endnode